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ABSTRACT 



This report Is a technical description of the 709** 
Compatible Time Sharing System in use at Project MAC and the 
M.I.T. Computation Center. It Is designed to acquaint a 
system programmer with the techniques of construction which 
were used In this particular time-sharing system. Separate 
chapters discuss the overall supervisor program flow; 
console message Input and output; the scheduling and storage 
algorithms; and a thumbnail sketch Is given of each of the 
subroutines which make up the supervisor program. 

This report was prepared with the aid of the compatible 
time-sharing system and the TYPSET and RUNOFF commands. 
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Preface 



The writer Intends these notes to provide a technical 
introduction to the operation of the 7094 Compatible Time 
Sharing System for a user who wishes to participate in 
programming and related development of the time-sharing 
system. In their present rough form, the notes attempt to 
fill as quickly at possible a need for tutorial 
documentation of the time-sharing system. 

The reader should have considerable experience in 
computer programming, including a knowledge of the machine 
language (FAP) of the 709* computer. He should also be at 
least a casual user of the time-sharing system and thus 
familiar with the operating characteristics of the system, 
and he should be familiar with the system description 
provided in the CTSS users* manual (1). However, when 
highly technical aspects of the 709* operation or special 
features of the time-sharing system are discussed, the notes 
will provide enough background material for a reader 
familiar with these subjects. 

JtJGJLft: In the interest of getting into distribution a maximum 
amount of information in a minimum amount of time, sections 
5,6, and 7 of the Technical totes consist mostly of tables 
and charts, with a minimum of verbal description. They 
should provide a useful reference source, though they are 
not Ideal for tutorial purposes. 



(l) f.j. Corbat6, et ai: jjn Compatible Time-Sharing 
svititi; A Pmf ramrnnr i fiulrirr m.i.t. Press, Cambridge, 

Mass.* 1963. 
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1. Introduction to the Technical Aspects of CTSS. 



In this section we will review several ideas which are 
covered in the CTSS Programmer's Guide* but from the point 
of view of a system Pfie^ammeir rafter than that of a user of 
the system* We will discuss* in turn, the computer on which 
the system operates; the overall design principles; the 
place Of the disk and drum memories in the system; the 
relation between the user and the supervisor; the types of 
commands; and finally* the modular construction of the 
system supervisor. 



Ihfi Computer. 

While many of the Ideas involved in the time-sharing 
system ere to Some exten t I ndependen t of the compu ter wh I ch 
the system uses, a technical discussion presently requires a 
specific reference to details of the particular computer. 
The computer in these notes Is the IBM ?09<t with several 
special features. The most important are; 



1. Core storage interval timer clock. This includes an 
"alarm clock" which can cause a program interruption 
similar to a data channel trap. 

2. Memory protection and relocation registers. These 
permit a section of the computer memory and certain 
instructions to be declared "off limits* 1 to a program; 
a trap will occur whenever a program attempts to tread 
"off limits." 

3. At least five data channels, connected to the following 
equipment: 

Channel A: Printer t punch, reader, tapes, and 
Chronolog clock. 

Channel 8: Tapes* 

Channel C: Disk end Drum Storage. 

Channel D? Direct data Input and output for special 
experiments* 

Channel E: 7750 Communications Channel (which 

communicates with typewriter consoles). 

The Project MAC Computer has two additional channels: 

Changed F: Disk and Drum Storage. 
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Channel G: High Speed Drum. 
k. Two 32K core storage modules. 

These special features are combined with an extensive 
supervisor program, known as the "time-sharing system 
supervisor" to provide a complete time-sharing system. 

PfiSlKP. Principle. 

It will be somewhat easier to understand the general 
import of the Ideas to be presented In these notes If some 
of the principles of design of the time-sharing system 
supervisor are stated clearly at this point. 

1. Although subsidiary computers (the IBM 7750) are 
an integral part of the system, as many functions as 
possible are carried out by the 709U. This centralization 
of supervisor control Is primarily to simplify the job of a 
person trying to learn how the system operates, 

2. The system is designed for the maximum possible 
interaction rate with the user: the 709U accepts each 
character as It Is typed by each user. It is not necessary 
for the user to communicate on a line-by-line or 
paragraph-by-paragraph basis with his program, although many 
programs do not attempt to take advantage of the maximum 
Interaction rate. 

3. Input and output from user programs are provided 
by supervisor subroutines which allow the user to specify by 
name the function he desires without irrelevant detail and 
bookkeeping on nf.s part. For example, If he wishes to store 
some Information on the disk he gives the supervisor the 
block of information and a name by which he knows the block; 
he can retrieve it later by asking for It by name. He need 
never worry about disk track numbers or complicated data 
channel programs. Similarly, the mechanics of communication 
with a typewriter console via telephone lines would deter 
even the most experienced programmer; but a subroutine call 

s provided which accepts a message and the Information that 
ft is to be typed on a console; the supervisor subroutine 
takes care of the rest of the details. This principle is 
carried to the point that the user is required to do all his 
1/0 via supervisor subroutine calls. 

.. fc *• , T he supervisor Is designed to be context-free. 
That is, although it accepts command.; from a user, it has no 
direct interest in what the commands do; It considers a 
command name to be merely the name of a program to be found 
In a directory; when the program has been found it is loaded 
and started just like a program written by the user. 
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lisa g£ BlsK dud Sum itataxa. 

As mentioned above/ Input and output are handled by 
supervisor subroutines for the user. This comment applies 
especially to the disk fll« and the magnetic drum memory. A 
special supervisor module, the disk control/ handles all 
Input and output for these units. The disk control module 
has been designed so that the user cannot distinguish 
between the disk and drum memories. There 'are four primary 
uses of the disk files: 

1. User files. These are files of Information which a 
user wishes to store away for future reference. They 
may consist of programs, data for programs/ or any 
other Information the user desires. They are kept on 
the disk indefinitely and allow a user to retrieve a 
program several weeks after he wrote it. Thus, the 
disk replaces the decks of cards and reels of magnetic 
tape usually associated with a large computer 
installation. 

2. Working programs. When a program actually works, it 
shareV the computer with several other users. Since 
not ajl of these users will fit Into core memory at 
once, * the excess are stored temporarily on the disk or 
drum to be brought Into the computer when their turn to 
use the central processor comes up again. 

3. Supervisor commands. Whenever a user types a super- 
visor command/ he implicitly requests execution of a 
program. In most cases, this command program Is kept 
on the disk. 

k. Scratch Pad memory. Many programs/ such as trans- 
lators/ require large blocks of temporary storage which 
do not fit Into core memory. The disk is also used to 
fulfill this nee<i. 

All files kept on the disk (and drum) are known to the 
user only by name: the supervisor disk control module keeps 
for each user a directory of names and corresponding track 
locations '<**» the disk* A simple chaining procedure is used 
to locate any given file. 

A master file directory, which contains the 
identification of all potential users of the system, starts 
at a fixed place on the disk and contains all pertinent 
Information about the user. Including the location of his 
personal file directory. His file directory lists names and 
starting locations on the disk of each of his personal 
files. Every user of the disk control module/ Including 
even the supervisor/ must appear in the master file 
directory. As will be seen later/ the supervisor modules 
are also stored In relocatable binary form as files on the 
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disk under the user number of a special BSS loader which 
starts up the system. 



Relation Between User, User Program* and Supervisor. 

For every possible user of the system, there is an 
entry in the Master File Directory of pertinent information 
about his identification and use privileges. There is no 
information/ however, about the nature of the console he 
might use; this information is not of interest to the 
supervisor and only concerns the user (and possibly his 
program) . 

When a user logs in to the system, he is assigned a 
user number and thereby becomes subject to the attention of 
the scheduling algorithm. A logged-in user is assigned a 
"state" according to the demands he is placing on the 
system; this "state" will usually change several times while 
he is using the system. Each state has an associated code 
number: 

0. "Dead". This state corresponds to a user without a 
program. He may be in this state because he has just 
logged in and has not yet loaded a program, or because 
his program has just completed execution and returned 
him to the dead state. In all states but this one (and 
sometimes state 3) there exists a "core image" of a 
program for this user. 

1. "Dormant". A user is In the dormant state when he has 
a program which is potentially runnable, but which for 
some reason the user does not want to execute at the 
moment. His program is probably not being kept in core 
memory but temporarily on the disk file, until he gives 
the word for it to begin execution. A user will be in 
this state if he has just loaded a program but has not 
yet started it; or if he has just finished program 
execution and returned to the dormant state. This 
latter possibility differs from the similar situation 
described under "dead" in that the core image of the 
program remains available either for rerunning or for 
postmortems. 

2. "Working". A user is in this state whenever his 
program is scheduled for execution. Working users 
actively share the use of the computer, but only one of 
them Is actually in execution at any given instant, 
while the others may be in core or stored as core 
images on the disk just like the dormant users. All of 
those trying to execute are considered to be in the 
working state. 
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3. "Waiting Command". If a user is in either the Dead or 
Dormant state/ anything he types is considered a 
command to the supervisor. When he finishes typing a 
command^ the supervisor places him in state 3 to 
indicate that he should be actively considered by the 
scheduling algorithm. When his turn comes to use the 
computer/ the correspond I ng command program is located/ 
loaded if necessary/ and his state is then changed to 
"working". Note that a command program is considered 
to be the user's program; once it is loaded it is 
indistinguishable from one of the user's own programs. 

k. "Input Wait". When a working user program attempts to 
read a line of input from the console typewriter/ there 
is a good chance that the user (typist) has not yet 
finished typing the line. In this case/ the user is 
assigned state k t and he Is temporarily ignored by the 
scheduling algorithm until such time as the needed line 
has arrived* Although In principle a request for input 
from any device could result In the input wait state, 
this state does not apply during the reading of a file 
of Information from the disk. The rate of information 
transfer in this case is so high that more time would 
be lost switching users than waiting for the first 
user's input to arrive. 

5. "Output Walt". When a user's program attempts to type 
out a series of messages on the typewriter console/ 
messages may be produced at a higher rate than the 
console can type. After a few such messages have been 
absorbed by Intermediate buffers/ the user is placed in 
state 5 until the messages clear sufficiently to permit 
the program to proceed. The output wait state could 
also apply to any output device requested by the user/ 
but considerations similar to those described under 
Input again apply. 

One further noteworthy detail of the present 
implementation makes clear future remarks. The two memory 
banks of the computer will be referred to as "memory A" and 
"memory B". The supervisor is In memory A/ and user 
programs are In memory B. It is not essential that such a 
division of equipment take place/ but a formalized division 
greatly simpl tfles the programming wl thin the supervisor. 



SUOerYiSOr Commands. 

A command program is nothing more or less than a 
complete program previously written by someone/ which Is 
stored In the form of a core image ready to load and run. A 
number of those command programs are considered "public 
commands" and are stored in the supervisor's disk files. 
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Other/ private command programs may be stored in a user's 
private file. Examples of public command programs are the 
MAD and FAP translator programs. An important aspect of the 
way in which the supervisor handles commands (requests for 
the execution of* a command program) is that the supervisor 
remains aloof, as it were, from the operation of the command 
program. 

Suppose a user types the command MAD with appropriate 
arguments. The supervisor accepts this ihput line after 
checking that it is in fact a command. When it Is the user's 
turn to run, the supervisor looks up the command name in a 
command directory which contains BCD command program names 
and command program starting locations. If the command 
named MAD Is found In the directory, the file named "MAD 
TSSDC." is read from the disk Into core B and started at 
the location given in the directory. This command program 
is now the user's program and runs exactly as If he had 
written and loaded it himself. Note, however, that the 
supervisor itself has jjo. information about the command or 
what it does, except its name and starting location. It is 
In this sense that the supervisor is conte^t - f req . 

There are, in fact, three kinds of commands; we have 
just described the operation of "disk-loaded" commands. A 
second type of command, also context-free, Is the B- core 
transfer command. If the user types a B-core transfer 
command and is in a dormant state (that is, has a B-core 
Image), his core image Is loaded and the transfer Is made to 
a special place in his program (again given in the 
supervisor's command directory). Examples of B-core 
transfer commands are PM and FAPDBG. These functions are 
carried out by subprograms which are loaded as part of the 
user's program. The third command type Is the A-core 
transfer command, which requests an action Intimately 
connected with the supervisor and Is thus not strictly 
context-free. Examples of this type are L0G0UT, L0GIN, and 
SAVE. Here no loading is needed, since the command programs 
are built into the A-core supervisor. 

Ihs. Modular Time Sharing ixsLtfim. 

The supervisor program has been written in the form of 
modules, for ease in understanding and modification. Each 
module of the supervisor takes charge of a specific 
function, such as typewriter coordination, disk file input 
and output, or scheduling of user programs. The modules are 
written In languages which produce binary programs In BSS 
relocatable form; thus the modules may communicate with each 
other only through the two standard communication procedures 
of BSS programs, namely the transfer vector and program 
common. Thus the number of interconnections between 
separate parts of the supervisor is minimized and such 
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interconnections can only exist on a formal/ advertised 
basis. Most importantly, the reader can study and 
understand the operation of a specific module while he 
still has but a vague idea of what happens inside other 
modules. Figure 1.1 is a schematic illustration of a layout 
in core memory of the modules of the supervisor program, and 
the user programs. The diagram shows only a few of the more 
important modules. 
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Figure 1.1 -- Possible core Memory Layout. 
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While the system is operating, the modules of the 
supervisor are in the form of a complete program loaded and 
linked together in core memory. However, copies of each 
module in BSS form are stored in the disk file. In 
to the modules normally used in the system there 
newer modules being debugged, or older modules 
backup in case the presently used version suddenly 
an unforeseen bug. The system is started up by placing a 
modified BSS loader into core memory and giving this loader 
a special control card which specifies a list of modules to 
be loaded and linked together. The steps involved in 
starting the system are as follows: first, a 709i» program 
loads the disk from a tape copy made of the disk following 
the latest previous use of the 
another 709U program loads and 
computer, which handles console 
Now, a special BSS loader which 



time-sharing system; then, 
starts operating the 7750 
typewriter input and output, 
contains a copy of the disk 
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control module 1$ loaded, f rem a card reader or tape/ Into 
the 709*. The loader Is followed by a ?*aupervlsor name 
card." The BSS loader has a uswr m»#e«*> and thus has 
access to the disk flies with the at* of tts disk control 
module. The "supervisor name card* specifies the n»«e of a 
disk file ace to the BSS lewder which contains a list 
of names of the dft sk files to be loaded to farm a supervisor 
program. 

There are two Interesting aspects of this procedure for 
loading the time-sharing system supervisor. First, maximum 
use Is made of existing programs, such as the disk control 
module. Second, If a module being checked out develops a 
bug, It can be very easily removed from the system (and an 
older, reliable version substituted) with a minimum of fuss 
and bother, simply by a reloading of the special BSS loader 
with a supervisor name card which specifiers a different list 
of disk flies to be loaded to produce the supervisor. This 
feature Is vital In a system which Is In use while still In 
a state of development. 

Epilogue. 

In conclusion, a picture of the magnitude of this 
undertaking, In terms of relative else of the programs 
Involved, may be of Interest. Th* supervisor program 
consists of about 14,4*00 <dec4«i»l* l^tttictlons plus tables. 
This figure compares with 11,000 fm the MAD compiler, 
10,000 for the FAP assembler, and some 60,000 instructions 
In the older IBM Fortran II compiler. Thus In the proper 
perspective, the time-sharing system supervisor Is an 
undertaking comparable to the development of a completely 
new compiler system. 1n eddf tlon *o thm FAP and MAO 
translators, command programs totaling another 6,000 
Instructions are necessary to frame out a "usable" time 
sharing system. 
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2. Construction of the Supervisor Program 

Introduction. 

In this section we examine the general flow of control 
within the supervisor program and consider when and how it 
obtains control, and what happens when It does. In doing 



o 



so, we will get a slightly closer, but not detailed view 
several of the Important supervisor modules. 

Supervisor Program, Flow. 

Suppose a user's program Is operating. The program is 

located In core B, and has control of the computer; the 

supervisor Is located In core A but is not presently in 

operation. There are three events which can cause the 

control of the computer to transfer to the supervisor, <s 
Indicated In figure 2.1. 

First, If any user at any typewriter types a character, 
he causes a data channel trap at the 7094 . Control passes 
to one of several special supervisor modules called 
Input-Output Adapters. The appropriate Adapter accepts the 
character, performs any necessary code conversions on it, 
and places It Into a common input pool buffer along with the 
typist's "user number". Control then returns to the 
interrupted program which continues as If nothing had 
happened. A data channel trap Is a true "Interruption" as 
it may occur at any point In the user's program. 

A second event which gives control to the supervisor Is 
the following: after a period of time known as a "clock 
burst," and typically of value 0.2 seconds, a clock trap 
occurs, which passes control of the computer to the 
supervisor clock trap processor. At this time the 
supervisor does most of Its "housekeeping" work. The 
typewriter coordinator processes Input and output between 
user programs and typewriter consoles. The supervisor 
examines commands typed by other users and makes notes. 
Finally, the supervisor consults the scheduling algorithm 
module to learn whether or not this user should be permitted 
another "clock burst" of running time. If he Is allowed to 
continue running, his program is restarted at the point at 
which It was Interrupted by the clock trap; If not, another 
user Is allowed to run, and a "swap* 1 may have to take place. 

We have thus far looked at two ways In which control 
may pass from the user's program to the supervisor. Both of 
these traps, data channel and clock, have the property that 
they may occur at any point In the user's program. The 
third event which causes control to pass to the supervisor 
however, Is completely under the user's control. This event 
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Is the (presumably) Intentional protection mode violation; 
the signal that the user Is calling on the supervisor to 
perform some special subroutine function. When such a 
subroutine call occurs/ of course/ the operation of the 
supervisor depends on exactly which subroutine has been 
requested. In general/ however/ If the user's state has not 
changed as a result of the subroutine call/ control returns 
to him directly as soon as the subroutine operation has 
finished/ unless he used up his "clock burst" during the 
operation of the subroutine. If the user's state has 
changed as a result of a subroutine call, for example/ a 
call which requests a change from working to dormant status/ 
control passes Instead to that portion of the supervisor 
concerned with locating and running another user program. 



fiflia channel and d PC K Traps* 

For the Interpretation of the flow diagram In figure 
2.1/ the operation of the data channel and clock traps must 
be understood. These two traps may be either enabled or 
disabled . In the supervisor/ they are almost always enabled 
and disabled together. If a trap Is enabled/ the program In 
operation/ whether user or supervisor/ may be interrupted at 
any time; the program has no control over Interruptions 
except to disable the traps. On the other hand If the traps 
are disabled/ when a trapping condition occurs the program 
Is not interrupted; instead the trap Is remembered untl 1 
such time as the traps are re-enabled (restored). The 
ability to disable traps, yet remember them. Is necessary In 
order that the supervisor may handle all traps In an orderly 
manner. 

The dotted boundary In figure 2.1 Is the disable-enable 
boundary; all programs Inside the boundary run with data 
channel and clock traps disabled/ those modules outside the 
boundary run with data channel and clock traps enabled. 
Thus a data channel trap cannot occur while in the 
scheduling module but may occur while In the disk control 
module. 

When a clock or data channel trap occurs/ further clock 
and data channel traps are Immediately disabled. The 
supervisor continues to run with traps disabled until It 
either returns to the Interrupted program or It goes to the 
sway (main control) section. 

Note that care must be taken to Insure that an enabled 
supervisor subprogram Is never entered following a trap from 
the very same program. To make sure that this does not 
happen, the clock trap processor never goes to the swap 
section If a trap has come from core A. Instead/ If a swap 
Is needed/ only a switch Is set/ and return Is made directly 
to the point of Interruption of the core-A subroutine. When 
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the subroutine has finished, It returns to the user program 
via the common user return RSTCPU, Since the user may have 
run out of time during the subroutine operation, RSTCPU 
checks the swap switch and If a swap Is needed, performs the 
transfer to the swap section whlcn the clock trap processor 
was afraid to do before. 



system Modules. 

After the brief consideration of a general picture of 
the supervisor operation, It may be useful here to list all 
of the modules with a brief sketch of their diverse 
purposes. The block diagram, figure 2.2, shows the general 
relationships between the various modules, although flow of 
control between modules Is not unambiguously Indicated. 



Ea 
subrout 
seconda 
module 
name ar 
and the 
version 
are spl 
ma y no t 
module, 
version 



ch module Is a subroutine, or group of related 
Ines, filed by a six-character primary name and a 
ry name corresponding to the language in which the 
is written. The first four characters of the primary 
e mnemonlcally related to the function of the module 

last two characters are a number Indicating the 

of the module. Some modules, because of their size, 
it between two or more files. Such a .split may or 

imply separateness of functions of the parts of the 
The names of the modules and their functions in the 

"1A1" system are: 



Primary File 
Name 

MAIN 

CL0C 

CTRL 

ST0R 

SCDA) 

SCDB 

SCDC 

SCDD 

SCDE 

SCDF 

SCDGJ 

TC0R 

PMTA 



Function 
Initialize time-sharing supervisor, 
Clock trap processor. 
Main Control Section. 
Storage algorithm. 

Scheduling algorithm.* 



Typewriter coordinator. 

Protection mode violation processor. 
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RTRN 

SAVR 
UTRP 

RFLX 
C0MC 
C0MD 
C0NV 
0NLN 
EDBG 

L0GA' 

L0GB 

L0GCJ 

SAVC 
0CTC 

DSKI 

ADPI 

AP75 

TST0 

CHNE 

HIGH 

UNIT 

DCER 



PL0TS 

or 
KLUD 



Common exit routines to return to 
trapped programs. 

Save and restore user machine conditions. 

Process STR, floating point/ and data 
channel traps for user programs. 

Processes user Input lines, 

Miscellaneous subroutines. 

Command directory (no instructions). 

BCD conversion routines. 

Do on-line 1/0 for supervisor. 

Post mortem and trace routines for 
debugging the supervisor. 

L0GIM/ L0G0UT commands.* 

Start, save, restor, resume commands. 
0CTLK, 0CTPAT, and 0CTTRA commands. 

Disk control . 

7750 I/O adapter. 

7750 Write subroutines. 

Assign 7750 storage.* 

Channel E hardware subroutines. 

High speed line adapter. 

Assign and look up logical user numbers. 

Handles channel E errors. 

Channel D I/O adapter. 



* Indicates a module written In the MAD language. The 
other modules are written In FAP, 

NOTE: More detail about the entry points of each module is 
contained in Chapter 7. 
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3. Input and Output 

Introduction. 

In this section we will study the communication between 
the user and his program in the time-sharing system. We 
will discuss specifically how a typewriter communicates with 
the system/ although the ideas can easily be extended to 
more exotic forms of Input and output devices 

To allow a continuous flow of Input or output between 
the typewriter and the user's program, which may not be in 
core memory at all times, the supervisor provides buffers 
for the data being transmitted. Input messages are buffered 
in core A, within the supervisor, while output messages are 
buffered in the 7750 computer. 

Ul£ General LQftic p_£ InPUt £JLSttt* 

Figure 3.1 Is a flow diagram of the handling of input 
from a typewriter by the time-sharing system. We may begin 
with a user typing a character on his typewriter. This 
character travels via telephone lines to the 7750 computer. 
The 7750 accepts the character, and turns on the 7909 data 
channel. The 7909 data channel places the input character 
in a buffer in the 709*» memory and causes a 709«* data 
channel trap to the appropriate 709U input adapter. The 
input adapter program moves the character Into a character 
pool buffer, In the form of a word containing the character 
In the address and logical user number In the decrement. 
This format, used for all character-oriented devices, is 
known as "Interface I". The character pool buffer is 
capable of holding about 600 such characters (for 30 users). 
The 709U then returns to whatever business It was about when 
the trap occured. 

The characters In the character pool buffer are thus 
left for a later section of the supervisor to examine and 
eventually route to the proper destination. It is 
fundamental that the 709U computer responds to input 
character by character so that if a user program desires, it 
can communicate back and forth on a character by character 
basis with the user. 

Further processing of Input resumes when a clock trap 
occurs, giving the supervisor program Intentional, complete 
control of the computer. At this time the input characters 
are processed in two stages. The first stage, handled by 
the typewriter coordinator module, collects characters into 
messages. Each user has a separate secondary read buffer, 
and all characters which he types are moved to his secondary 
read buffer by the typewriter coordinator. No further 
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action Is taken unless one of the characters typed by the 
user Is found to be a "break" character such as a carriage 
return or other special character designated by his program 
as a break character. When a break character Is found among 
the Input characters his message is considered to be 
complete/ and no more characters are placed in his secondary 
read buffer. If more characters remain in the character 
pool buffer for this user, they are left there until his 
secondary read buffer is free. A program switch is set to 
indicate that this user has completed typing a message. The 
typewriter coordinator attempts to thus dispose of all of 
the characters in the character pool buffer by distributing 
them to user secondary read buffers. 

When the typewriter coordinator is finished moving 
characters into the secondary read buffers, the second stage 
of input processing begins. At this stage, handled by the 
clock trap processor module, completed messages are 
delivered to their final recipients' "mailboxes". If the 
user Is at command level (dead or dormant) the message is a 
command and is placed in the user's command buffer. If the 
user Is not at command level, the message is for his 
program, and so it is moved to the "user lines" buffer. 
There the message remains until his program calls upon the 
supervisor subprogram RDFLX for final delivery. 

Note that the second stage, which removes the message 
from the secondary read buffer, is not strictly necessary; 
the user's secondary read buffer could be considered as his 
mailbox. The second stage could consist only of noting 
completed messages from users at command level. A floating 
buffer scheme to do this simplification could easily be 
implemented. 

An important reason for the modular construction of the 
system supervisor is well illustrated by the input scheme. 
There may be any number of input adapter modules 
communicating with character-oriented devices. Each of 
these modules, upon obtaining control from a data channel 
trap caused by its hardware input device, can place 
characters in the character pool buffer in the standard 
Interface I format. The processing done by the typewriter 
coordinator ts completely independent of the source of the 
character in the character pool buffer. The adapters can be 
considered as "matching devices" between the specialized 
hardware requirements of different input devices and the 
standardized characteristics of the input interface of the 
typewriter coordinator. 

XtLSL General logjc pi Qytput Flow. 

Having looked briefly at the input side of 
communication between user and user program, we will 
postpone detailed discussion of the Input modules until we 
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have turvtyd the related output *^f~ i| ,g ut ^l e ,$ ne ^M?y 
in * w*v autte e tattler to Input but with some necessary 

Su?pu1%roSie^ Jw-ny^M PTO*rim off If too. much 
output comes out In too short * time; -the Input P r °c«ssor 
cannol turn off a typist wl thou* fancying him and perhaps 
losing some of Ms typed characters. 

Thus one can make sure during Input that the system 
keeps up with the typists by making the character pool 
buffer large enough to accept the maximum number of 
characters that all the typists could produce In, say, two 
seconds. Then, If the typewriter coordinator attempts J* 
empty th. character pool buffer at least once Par second, 
only very rarely will the buffer overflow and the typists 
told to desist* 

In contrast, the output sections of the su ^^ or 1 ffl ^J 
constantly exoect to be pverbwrdaiiad iwlth output » ,nes 
pr^c^dby ££rWwhich ru* factor than the typewriters. 

The supervlsoT handles the ***»-/•" •*E 1 r. roam for iRe 
to accept output from a progi^uaJes* there Is room for the 

dStSln the SSpu* buffers, "Jf^ MfSF*- •" f " h L' ^ 
user's orogrem Is placed In "output wait* status. The user 
P rtgram P d^!*i rituro to :Mf| #tatus ? until buffer space 
Is available for the program's output. 

With these |»nslderatloi» In mind, w* can now look at 

figure 3.2, a floM diggram of ou*Pu*, % , WOCessIng, ^'J"' 

orlglnatis when ;the uaer's pr«*r*m «*1t lor the *«PJ™lsor 
sub-program WRFLX or WRFLXA. The user *s «*$•?»• Jl 
converted to 12-blt form If It Is not •«•{»; that form 
??hI*lB If the user is In the normal, S-b.lt mode) and 
loved nto thi^r Imary write buffer, this buffer has room 
fS? 29 woTds; since three 12-blt characters are stored In a 
wSrd, therfls room for a •* Una* of te characters Plus a 
carriage return. 

Subroutine wRFUC now calls the output adapter module at 
the entry point W*T€t¥ to write the? information out on the 
mO^PUter. The output «*ej**r ^A****™ *" haSe 
return, however, to lndlcat**ha* the 71*0 ^« ot lt *% m f 
room for the message. If this Is the case* WRFW •««!; 
performs an error return which o!*c#* jbo user '««"*?«? 
wait status, when space becomes jjllsMj, the 7750 will 
send a completion signal back to the 1W*, and this user 
Jill come beck, to working stetus. As soon as the user 
biglnS^xecutlng agal*, subroutine HR8U| W^ Jj£. 
the beginning, moving the message Into the primary^ write 
buffer (since the buffer may have ^an used by someone else 
while the first user was In output wait). 
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Figure 3.2 — Output flow. (TCOORD and WRTELY) 



Assuming, however, that the 7750 has room for the 
message, the output adapter encodes the message and delivers 
It to the 7750. A detailed description of the output 
adapter, and of the criterion used to determine whether or 
not the 7750 has "room" for a message is the subject of the 



next section. 
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WRFLX also does some processing of the output line. It 
locates the last non-blank character fn the line and inserts 
a carriage return character after I t, while It deletes the 
trailing blanks. For those applications where this 
processing is not desired, an alternate entry, WRFLXA is 
provided which puts out the line exactly as given. 

Since calls to WRFLX and WRFLXA always must specify an 
integral number of words, they also always specify a 
multiple of 3 or 6 characters, depending on the status of 
FULSW. In those cases where a different number of 
characters is desired, the null character, 57 (octal) may be 
inserted to fill out the last word In the block. The 
typewriter coordinator will ignore null characters found in 
the secondary write buffer. 

Note that the only communication between the 
input-output adapter (the two functions are really handled 
by a single module) and the rest of the supervisor is via 
the primary read buffer (Interface I) and the 
subroutine-type call to the output adapter. The resulting 
independence makes it very easy to remove one I/O adapter 
program and insert another for a different class of 
input-output devices. 



An -US- Adapter Module . 

We are now familiar enough with the general logic of 
Input and output to study In detail the modules which 
perform it. We start with an I/O adapter module, but 
remember that this is only a description of a typical 
adapter module and that any other program with similar 
characteristics with respect to the primary input and output 
buffers can, and occasionally does, replace the particular 
one we are studying. 

The I/O adapter module is of course split into two 
quite Independent parts, one handling input and the other 
output. Let us consider the output section first, as 
illustrated in figure 3.2. The output adapter performs the 
necessary code conversion for the user's particular device 
(teletype, 1050, flexowrlter, etc.) and places the data in 
the proper format for the 7750, one character per word, with 
the user's telephone line number in the decrement. The 
supervisor module UNIT maintains a table of correspondence 
between actual user, as identified by telephone line 
numbers, and internal logical user numbers. Each user, as 
he dials Into the system, is assigned a logical user number 
for easy Identification. The adapter must then establish 
whether or not there Is room for the message In the 7750 
buffer area. A separate module, TST0, keeps track of how 
much space is available In the 7750, and this module also 
decides the policy of who should be allowed how much space 
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there. There Is room for 10/000 characters In the 7750 
buffer, and the amount which any user may have is known ab 
his allotment/ AL0T. If N characters are actually in use at 
the time a user asks for output space, his allotment is 
calculated as 

AL0T = (10000 - N)/i» 

If the total number of his characters in the 7750 will not 
exceed AL0T, he is allowed to perform his output. If he 
will exceed AL0T, an error return is given to indicate that 
he should go into output wait. 

Consider now the input adapter module, figure 3.3. hi 
this case, control comes to the input half of the modulo via 
a data channel trap; there is at least one character in the 
adapter's input buffer. The input adapter picks up the 
character, converts It from the 7750 format to Interface I 
format for the character pool buffer and replaces the user 
telephone line number with his internal logical user number. 
It then checks to see if this character is really a 
completion signal from the 7750 saying that a 31 character 
buffer has been typed out on this user's typewriter. If it 
is a completion signal/ the adapter calls TST0 (?t entry 
point TGIVE) to tell it to release a block of 31 characters 
assigned to this user. All other characters are placed into 
the character pool buffer for later processing by calling 
entry point T0P00L in the typewriter coordinator. The input 
adapter restarts the 7909 data channel program, and return:, 
via the common exit module to the program that was 
interrupted by the data channel trap. 



Uti£ Typewriter Coordinator Module.. 

Figure 3.1* is a flow diagram of the typewriter 
coordinator program. As indicated, the coordinator only 
handles input processing. Actually, WRFLX and WRFLXA, 
described previously, are written as part of the typewriter 
coordinator module. 

The typewriter coordinator Is called as a subroutine 
once every time a clock trap occurs, by the clock trap 
processor. Its purpose, you may recall, is to collect 
characters from the character pool buffer into messages in 
individual secondary read buffers. The coordinator begins 
by examining the characters In the character pool buffer at 
one time. Let us follow the path of processing of a single 
character. First, the character is checked to see if it is 
one of the characters In the break character list. If It is 
one of the three special "quit-class" characters, (quit, 
Interrupt, or data-phone hang-up) this character by Itself 
Is considered to be a complete message to the supervisor, 
and the ILINES table is set to indicate that there is a 
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Figure 3.3 — Input Adapter Flow Diagram. 



waiting message from this user. To alert 
that this Is a special message, the prefix 
Is set to MZE and the quit-class character 
address of I LINES(USER) . If the character 



the supervisor 

of ILINES(USER) 

is placed in the 

is not a break 
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Figure 3,k -- Flow diagram of Typewriter Coordinator. 



character it 
read buffer, 
any room left 

Is full, the variable ILINES(USER) will contain 
non-zero buffer address; this is an indication to 
coordinator program not to attempt to use the secondary 
buffer. Instead, this character Is put back into 
character pool buffer. 



will have to be moved Into the user's secondary 

so the program then checks to see if there is 

in the secondary read buffer. If the buffer 

some 

the 

read 



the 



Assuming that all these tests are passed, the program 
then checks the variable FULSW(USER) to determine whether or 
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not the user's program is using a full (12-blt BCD) mode. 
If the user is using the ordinary 6-bit mode/ the 12-bit 
character coming from the typewriter will have to be 
translated. This translation includes two important 
features. First, if the character is either the "delete 
line" or "delete preceding character," the line, or last 
character, in the user's secondary read buffer is discarded. 
Secondly, on all other characters a mapping Is performed, 
when possible, from the 12-blt character to one of the 
allowed 6-blt BCD characters. For example, a small letter 
"a" and a capital letter "A" can both be mapped Into the BCD 
letter "A" with octal code 21; however, certain special 
characters such as the semicolon have no possible mapping 
into 6-bit codes. If these non-mappable characters are 
encountered, they are discarded at this point. 

Having performed a 12-to-6 bit conversion when 
necessary, all characters other than quit-class break 
characters are stored In the user's secondary read buffer, 
packed either 3 or 6 characters per word, depending on 
whether the user Is using 12-blt or 6-blt mode. The final 
check is to see either If the character is an ordinary break 
(end-of-message) character or if it filled up the secondary 
read buffer. If either case is true, the variable 
ILINES(USER) Is set to contain "PZE FIRST, ,n" where FIRST Is 
the address of the secondary read buffer, and "n" is the 
number of words in the buffer. This is the Indication to 
the supervisor that this user has a complete, waiting input 
1 ine. 

This entire processing operation is repeated once for 
each character found in the character pool buffer. We have 
not discussed here the Inter-console communication 
facilities provided by the AD0PT feature of the typewriter 
coordinator. 

Typical buffer sizes used by the typewriter coordinator 
are: 

Primary read (Character Pool) buffer: 600 characters 

(for 30 users). 
Secondary read buffer; 2 per user: 1U words. 
Primary write buffer; 1 Only: 29 words (1 line). 

The typewriter coordinator consists of about 500 
Instructions and about 2000 words of buffer space. 



1 I 
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fiJLhcx iza Devices: Interface JUL. 

So far, the discussion has been restricted to 
character-oriented Input/output devices, including the 
typewriter. All such devices have worked through the 
character interface of the tlme^aharing system/ known as 
interface I. Any character'!' type device can easily be 
attached to the system by providing an I/O adapter program 
which converts the raw hardware interface into the standard 
format of Interface I, whjeh consists of one character/word 
in the character pool buffer* 

There Is also another broad class of devices, such as 
magnetic tape, which work In terms of words, and blocks of 
words. A second Interface is provided for these devices. 
The details of Interface 11. can be found In M.I.T. 
Computation Center memorandum CC-226. For any input or 
output device for which interface II appears to be 
appropriate, an I/O adapter module may be written to perform 
the function of matching the hardware characteristics to 
Interface 1 I . 
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it. The Scheduling Algorithm and the Storage Algorithm 



Introduction. 

In this section we examine the operation of two 
Important modules of the time ••hewing supervisor: the 
module which decides who should run next antf^or how long, 
and the module which allocates the u**r* metaory area among 
various user programs* These two ftmettone* scheduling and 
allocation, are In fact closely releted* and have been 
separated in the supervisor because the particular 
algorithms used permit the separate cons I deration of the two 
problems. A more complex alj consider both of 

these functions slmultam and therefore encompass both 

modules. A thi rd function, >a%*#rept into 

both of these modules, a nofcrfttetly bandied by a 

separate module. The proper arr angem e n t of- these functions 
Is still open to debate, and the? modules described here may 
not represent the best possible organisation* 



The Schedul Ing Algorithm 

All scheduling policy is contained in the scheduling 
module; in fact no mechanics of the time-sharing system are 
performed by this module. The scheduling module i s for the 
rest of the supervisor a sage who Is occasionally asked for 
an opinion, but not asked to do anything else. Since 
mechanics are absent, the schedul Ing module Is well suited 
to the MAD language. In which it Is written. Since it is 
hardly necessary to write an involved description of a 
well -organized MAO program, only the policy involved will be 
stated. A reader Interested in exploring how the policy is 
carried out can easily understand the program itself. The 
explanatory comments at the beginning of the program serve 
to provide sufficient documentation. 



A .Typical Scheduling Pol Icy 

The particular scheduling policy described here is not 
the only such pol Icy, and may not be the best policy, 
particularly in the choice of the parameters given in the 
program listing. However, it is a typical policy, and the 
parameters given are typical parameters. If one concludes 
that a different parameter, or a completely different 
policy, will produce better results, then a different 
version of the schedul ing algorithm may be easily inserted 
into the system instead. Here, then, are the important 
aspects of this algorithm. Figure fc.1 is a flow diagram of 
the scheduling algorithm which nay be easier to follow than 
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the program Itself on the first reading of the policy rules. 
These rules apply to system version 1A3. 

1. All users In state 2 or 3, "working" or "waiting 
command/" are kept In a set of queues , which may be 
considered to be one long queue of users to run. In 
order. 

2. The queues may be re-ordered at the end of each clock 
period or more frequently, depending on events 
occurring during that clock period. A clock period is 
a short period of time, typically 200 ms., during which 
some user program runs uninterrupted except for data 
channel traps. 

3. Each queue has an integer valued priority level. In 
general, all the users in the queue with level "j " are 
run before any users in the queue with level "j+1". 
There are MAXLVL+1 levels, numbered from 0. 
(Typically, there may be 9 levels.) 

k. A "quantum" is the shortest period of time the 

algorithm ever attempts to run a user. A user may run 
more than one quantum, depending on his level. A user 
at level "j" is normally allowed to run 2.P.j quanta, 
although he may be preempted by the arrival of a user 
with higher priority. 

5. A user at level "j" is moved to level "j+1" after he 
has run 2.P.J quanta at level "j". Usually, he then 
stops running in favor of other users at level "j". 

6. A user at level "j" is moved to level "j-1" after he 
has waited "QNTWAT" 60ths seconds without running at 
all. Typically, this waiting time may be 60 seconds. 

7. A user starts at a level depending on his program 
length such that the time required to load his program 
Is a fixed proportion of the running time permitted at 
that level. This proportion fixes roughly the maximum 
efficiency of the system. (The efficiency may be 
lower, because of pre-emption. See JL, below.) The 
"level of entry" function can easily be changed to 
reflect a different policy. 

8. A user at level "j " may be pre-empted at the end of the 
next clock burst by a user entering the queues with a 
higher priority. The pre-emption will take place if 
the user now running has run longer than would the 
pre-emptor. 
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EVENT 
system - 
startup 



initial U« SCHEDt 



$WAP#— 1 
NfH0$R«— U 
run background 



•©turn 



EVENT 1 
clock 
Interrupt 
(200 ms) 



if»ve Ions waiting 
users to end of 
higher priority 
queue 



move long running 

current user to end|»»decide 

of lower priority 

queue 



Q » DEAQ 



H"*""«^«»*« 



jDelete from 
»u eues. 



>dec I de 



"tt 



ielete from 
l"f¥ff 




^Hfritnt ^ec i de 

•.user 

gther — ^ 

usaf return 



EVENT 2^ 
a user 
changed 
state 



Dispatch 

on 

new 

f I* If 



B"7 



mis state 

fr or ■ ** 



no 



"" ^ "return 

compute I 

level basedPdec I de 



ylst-a*Js&LJejl*Jfch. 



3 » hfalting 



[Compute 
{based on 
1 length 



level 



'decide 



t 



4.S « i/0 WAIT 



[delete from 
queues 



decide 



EVENT 3 

dumping of old 
user begins 



charge old user for running time 



•return 



EVENT 4 -* 

dumping of old 
user done; load 
of new user 
begins 



charge old user 


for dumping time 


unless new user 


has higher 


priority or old 


user 4s background 


else charge new 


user for dump. 



> 



return 



figure e.l— -Flow diagram of Scheduling Algorithm. (SCHEDL.) 



***m tw*m m m > m#>Kx > 
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Flow diagram of Scheduling Algorithm (cont.) 



EVENT 5- w— | 

restor i ng of news 
user done. New, 
user to begin 
running 



charge new user for restoring time 
unless backgound Is new user, in 
which case charge old user. Set 
new user to run for time based on 

lEYEirt V _ — : 



-HSWAPt-01 
decide 



EVENT 6 — 

user changed 
1 ength 



HSet LEJjft&ft of user. L not f.urrftnt ,»dec I de 



current 



user 



user 



Compute LEVEL but don't change 
queues . Al I ow 1 onger runn i ng 
time if new LEVEL is of lower 
priority t|i#» previous LEVEL. 



-^return 



dec i de- 



•♦ lis SWAP non-zero?! yeT 



Is head of queues user 

different from current 

*5?r1 



no 



■?*■*■'■ 



Has current xis&r run for as long 
as hea4 af queues user will? 



SWAP 4—1 

NEWUSR*-— head of queues user 

OLDUSR^r^c^yrrent user 



I 



"Return 



•>return 



no 



►return 



return 



(When the SWAP switch i s set non-zero, the supervisor will 
call EVENT'S 3/ <t, and 5 In succession as soon as it can. 
NEWUSft will be the next user to run. 



figure «i,X^-F low diagram of Scheduling Algorithm. (SCHEDL.) 



'■■'■■;' ■ ',:,,."■"_■ T ;"- ' : ';v'"'' ''' : ' ":-*'. 
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9. When a user leaves states 2 or 3 he Is removed from the 
queues. When he returns to state 2 or 3 he is assigned 
a new priority level; hi* previous running time is not 
taken into cons I deration; -TtHft^tfuf algorithm concerns 
Itself primarily with fanning times within 
interactions. A program celling for * new commend is 
not considered a new Interaction, out It* level may be 
changed if the new command i» longer. 

10. If a user returns to state 3 or 3 he Is placed at the 
end of the queue at his priority level based on program 
length. 

Ike. Background ixaJLfflP. 

It will be seen from the program coding that one user, 
user number zero, may be accorded special treatment at 
various points in the algorithm. Use? aero represents the 
background batch-processing system which is maintained by 
the supervisor both for compatibility with older systems and 
to provide a guaranteed backlog of work for the computer in 
case no regular ("foreground") users should need service for 
a time. The following additional pol Icy rules describe the 
position of the background system with respect to the other 
'users: ■ 

11. The background system is always at the end of the queue 
of users to be run. If the queue should become empty, 
the background system will then run until some other 
user enters the queue. 

12. The background operator may "force" the background 
system to be flin by depressing certain keys on his 
console. The background system will be brought In at 
the next clock trap, an<k run exclusively until the 
operator signals that normal, * I me-sha red operation 
should continue. 

13. it is possible to guarantee the background system a 
certain percentage of the facility of the computer, by 
setting the variable "PB" to the desired percentege in 
the initialization of the algorithm. When "PB" is 
non-zero, the background system will pre-empt whenever 
it falls behind its guaranteed percentage* 

Pol Icy £Q£tuU£ft& 

The above enumerotion of policy rules does not describe 

if fka /.rirffn* In + h« «>h«Hii1ln# atcaptttim rnodulii. As 

Of 

This 

and 
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5. (See program listing for definition of an "event.") A 
brief description of this charging policy can be stated in 
the following five rules: 

1. Each user pays for central processor time used. 

2. A user mav pay for the time It takes to load him and 
dump him depending on whom he follows or precedes. 
Note that with the present storage algorithm, loading 
and dumping of a user are not overlapped with 
computation. 

3. The background system is specially privileged; It never 
pays for loading or dumping itself. 

<». With the exception of background, all users pay for 
their own load time. The previous user pays for 
background loading time. 

5. A user pays for his dump unless he is being pre-empted 

by a higher-priority user. In the latter case, the 

higher priority user pays for the dump. The next user 
always pays for a background dump. 

The "Onion-Skin" Storage Algorithm. 

The storage allocation algorithm presently used by the 
time-sharing supervisor has as Its main virtue simplicity. 
There is no question that a more sophisticated procedure can 
be devised, and will be when time permits. However, even 
the present simple allocation algorithm illustrates some of 
the Important features which must be possessed by any 
storage algorithm. 

The simplicity of the storage allocation algorithm 
results from two basic features: dumping and loading of user 
programs are not overlapped with computation, and relocation 
of user programs is not attempted. Thus all users are 
loaded starting at absolute location zero. 

The simplest possible storage algorithm would operate 
as follows: when a user must be dumped on to the drum, his 
entire program is dumped; assuming only one user in memory 
at a time, all of memory is now available for the next 
program, when necessary. The current storage algorithm 
attempts to Improve this performance by dumping only enough 
of a user to fit In the next user; the earlier user is 
therefore split into two parts, the one part on the drum 
memory, and the other part in core memory, where Its 
integrity Is insured by the memory protection feature. Thus 
if the first user should be allowed to return to core memory 
his next loading can be done more quickly than in the case 
where he was completely dumped from core memory. 



CTSS Technical Notes PAGE 32 

Since a third user, fol lowing the *eeeo«4, mar be larger 
than the second, It may be necessary at a fcater time to dump 
more of the f Irst user. ' : v*i' y^- 

To Illustrate the splitting, consider figures 4.2-«».6, 
In which several successive states of the user memory area 
are shown. In «».2, user A Is occupying most of core memory, 
and Is about to be dumped In fe«or of d«*r B. Following the 
dump, core memory appears In fig. #,3, with part of user A 
In core, part on the 4r urn. How, user e^ l» to be brought 
into memory, so user B is spilt In the same fashion, as 
shown in figure «».<♦. If the next user, »D, requires a larger 
space, as indicated In fig. *.«, C must be completely 
dumped* the dump b*f B must b«fi^l«he^^a^ tile dump of A 
continued a Tittle farther. The result Is shown in «».5. If 
now, following user 0, user A is to run again, the dump of 
user D wi 1 V have to %e complete but enfy the part of A which 
was dumped will have to be restore*^ -thus ^aayti^^some time. 
The result Is shown In <».6. 

In this example, only two usar*^ A awd », were spilt 

between memory and the drum at one t*t*e« As many as 16 

users may be split between : : corie aw# tha ddfWRr AH dumps 
onto the drum are made In blocks of 2<Mif words. 

Although In the illustration only a small amount of 
time was saved ultimately by not dumping all of A at first, 
in a different situation the technique assy ha much more 
effective. Cons tear for exempt*, t**e situation when only 
two or three console users, each mHk smell programs, are 
using the system, wiffe ba^gra)*n*V.^»^fnt^ar4*r^. -ahara of 
the time. Slncd background :*>$ mfriffr •******&**** *»* of 
It remains In cora at all times; only enough <*g dumped to 
make room for the smaller foreground users **en they need 
time. In this case, time saving can be large. 

The user aura* 

When a user is dumped from ewe* memory, a file Is 
created on the drum memory. This file Includes two 
sections: 

1. The User machine conditions status table, and the 
User disk status table; (Including tha current 
section of hi a user filar #i#sea%ery> 

2. The user's core Image. v 

The second section la not wrlttan -far a user going to the 
"dead" state. The file created is of temporary mode, end 
named w 0000 21 UDOMP." for user 21, etc. This file Is 
considered one of the suparviaor'a^araoaal files and does 
not appear in the user's file directory. 
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In figures 4.8, 4.9 and 4.10, are Illustrated the three 
subroutines of the storage algorithm, DUMP, UNDUMP, and 
FREEUP. DUMP and UNDUMP are subroutines called by the 
supervisor to perform the functions Indicated by their name. 
The following notes may help In interpretation of these flow 
diagrams. 

1. If DUMP is called to dump a working status user, 
it actually only dumps his machine and disc status 
tables and leaves the core memory dump to the 
routine which tries to make room for the next 
user. This Is done because at the time the order 
is given to dump a user It is not known how much 
of him will have to go. 

2. UNDUMP calls on subroutine FREEUP to dump out 
enough space for the new user to fit into core. 
Only then can It restore the new user core image 
and his status tables. 

3. Subroutine FREEUP Is called with one parameter 
("NWORDS"), the number of words of core memory 
needed for the next user. 



w - 'imwi^iipw^^^ 



CTSS Tec hn leal Notes 



PAGE 34 



User area 

of 
Core Memory 



space 
used by"] 
A 



space 
ne«de< 
by B 







rema 1 n 1 ng / 
part of J 

A | A 


space \ 
used 1 
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figures 4.2-4.6— The Onion Skin Storage Algorithm. 
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DUMP 



Call SCHEDL 
(Event 3) 



tS there room 
on high speed 
arum for user 



1 



yes 



Dump machine 
conditions & 

£tsk s tatus 
» i H i Mi l ■ H I I K iii lll. il I ' i l l I 



f^ 



Return 



no 



Dump al 1 of 
user* on low 
speed drum 
or disk thru 
read buffer 



figure «»,7-rFl©w d lag ram of subroutine DUMP. 



UHD.UMP 



I 



Call FREEUP 
to make room 
In core . . 



Call S#»EDL. 



<*n*. 



Restore user 



jiUflSL 



call SCHEDL. 



T 



Return 



figure «».8— Flow diagram of subroutine UNDUMP. 
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FREEWP 



i 



I I nd smallest 
»ser with a 
>artla! dump 
< I f any) 



T 



Any active 
partial 
user dump 
ffiundi 



T 



if** 



Is this user 
core Image 
.G. -fffifJBS 



T 



no 



I 



Inlsh dump 
or thfs user 



Write out 
enough words 
to mks room 
for WQftflS I 



no 



ye* 



'eturn 



Return 



Figure U.9 -- Flow diagram of subroutine FREEUP. 
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Appendix <t.A 
States of a User 



dead 



output wait 



nout wal t 



dormant 




wa i t i ng command 



Figure <f. 10 



Additional transitions not shown: 



1. Quit signal - any state to "dormant" 

2. Forced LOGOUT - any state to "waiting command" 



Description of states: 

dead - not waiting to run and no core image; 
command level . 

1 dormant - not waiting to run but has core Image; 
command level. 

2 working - waiting in queues to run or running. 

3 waiting command - watting in queues for first run 
of a command. 

«♦ input wait - program waiting for Input from console. 
5 output wait - typewriter output buffers filled. 



All input from the console is interpreted as commands when a 
user is dead or dormant. He is said to be at command level 
when in either of these two states. 
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Description of Transition* 



dead to 



- the u*pf typed In a defined 



command and Is placed in the queuas to waft his turn to run 

.. ... - the user begins to run the 

command for the fJrst time. From now on tile command program 
is treated exactly like a user prdsram* 

the console and the user has not yet typed In an input Vina. 
(RDFLX) 

T nnuf —it-.tn^rkina - the user typed In an Input line 
terminated with a break character. 

WfirKinir tft ffUtPUt Wit - the user ^s ^otcam^ has generated 
enough output to fill the output buffer** (HRFIX) 

p..»nut wait f Q irking - the output buffers are empty. 



worKins to 



-the user's program issued a 



command. CCHNC0M or NEXC0M) . 

Yfnrhlnf ffl tenant - the user's Program finked Its 
computation but the core image is atiW useful. CDWWTi 



rfartimnt to iff »f *»« -a*— and ». the user typed In a def I ned 
command which may operate on bis ©ore hatge or may destroy 
It and start fresh. 



W/^klmr * ft daad 



the user's pffifam finished Its 



computat i on Kd the core image is to be destroyed (DEAD). 

fo»r*nt t» wnricln. - «uo«rvlaor is restajrting the user's 
program without a console interact Jon* (SLEEP) 



piMBWiiWUiiMMt I . HIP'.- i .it »i J 'i iwiM » .iJMJ.WIIIllJlpil I^P PJ i, l.jl l iiliW iPiljipiPpppipp 
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>****• TIME SHARING 
T. HAST 1 AND R. 



SCHEDULING 



ALGORITHM 



THE SCHEDULING ALGORITHM P€R?ORMS TtR; FOLLOWING FUNCTIONS 



1. 
2. 
3. 

k. 
5. 



WHICH USER |$ TO RUN NEXT 
WHEN Nffjf imt1?-1t TO RUN 
MOW LONG NJIXT USER* 1S TO RUN 
CHARGES USERS FOR SWAPPING AND RUNNING TIME 
KEEPS TRACK OF WE STATUS OF €ACl* USER 



DETERMINES 

DETE 

DETERMINES 



THE SCHEDULING ALGORITHM IS CALLfO FROM THE SUPERVI SOR^ BY 
EXECUTE SCHBO.<EVENT, US£R> Ami) 
AFTER AH TR*>$ HAW BfE# & S*9i€D 
•USER 1 IS BtTWEfN ANf> T#fe ? ftfcit t N#. OF USERS, 'MXUSR' 
THE SIGNtFfC/AflOt OF ''OffR* AN© ♦ARG^ OH>END ON 'EVENT* 
OR ARE MfAWNGLE*^ WWll SELOW 
1 EVENT* DESCRIPTION 

tWTMtlZATKiN OF SCHED. 
CLOCK RRUPT 

'UStR* HAT 

beginning; of 

BEGINNING Of 
'USER* tfe6jj# 
•USER* ' : W T( 
OPERATOR SE¥ 1 
*OSfR* : ''i&gff£ 

HteF-imB, 
t.s "naiwff- JffS 



o 
i 

2 
3 

5 

6 
7 

9 
10 
11 



i ^ is £ i Si.' 



w?;NPw,' 



TO^STATE 'ARC 

ft* CORE IMAGE 
jftfeff CORE IMAGE 
R SWAP- 
LENGTH »AR6' 
fr TO *ARG' 
TtflTNE MULTIPLIER 



'USER 1 OlAUi 



RUNMLE 
UrcOMFVWt 



ALL TIME IS KEPT IN SIXTIETHS Of A S4&QND AND VARIABLES 
END I NG W I TN * Tl M* ARE TiHgS Si NO E* SYSTEM WAS 
LOADED WITH THE EXCEPT JjPJt AF * SYSTEM' 



SCHED. HAS SOiE RESPONjS rfffcftlP f 
THE FOLLOWING COMMON ARJR^T 




I^G AND 



CHANGING 



THE FOLLOWING COMMON ARRAYS ARE UfEjfr 
•STATUS* - THE STATUS OF EACH USER 
INHERE STATUSCJ) MAY Of 

OEAtf - NOT WAfTINO TO RUN ffl) NO CORE IMAGE 
DORMNT - NOT WAITING TO RUtT 



1 
2 
3 

k 
5 
LENGTH 



WORKING.- WAITING 
WAltrW COMMAND- 
input wait - 
output wait - 

* - LENGTH Of USER* 




RUNN I NG 
S £OR 
,„„ INPUT 

Gfe !N WORDS 



COM. 



•LEVEL' - USER'S PRIORITY t&VEtitf, „. . , 'MAXLVL 
' T I ML E V ' - EL APS ED T I ME RuIFaT tURRE NT LfVtt 
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R 'WATTIM' - THE LAST TIME THAT A USER BEGAN TO WAIT 

R 'LINMUL' - USER LINE MULTIPLIER 

R ■■PL 1ST 1 '.- THE POSITION LIST SPECIFIES THE POSITIONS 

R OF THE USERS WHICH ARE IN THE WORKING QUEUE 

R *ULIST* - THE USER LIST INDleCAfES THE M&ER NUMBERS 

R WHICH CORRESPOND TO THtSE QUEUE POSITIONS 

R 'ENDPTR' - ENOPTR(J) I S END OF QUEUE U IN PLIST 

R 'NOTIME' - NOT*M£U> IS SET TO 2 IF USER INACTIVE 

R AND USER J WILL SUBSEQUENTLY BE LOGGED OUT 

R 

R THE FOLLOWING COMMON VARIABLES ABE USED 

R MXUSRS' - MAX. NO. OF FOREGROUND USERS 

R 'CURUSR' - CURRENT USER, RUNNLNG OR SWAPPING 

R 'OLDUSR' - LAST USER TO BE RUN* WHEN *$WAP' .NE. 

R 'NEWUSR' - NEXT USER TO BE RUN* WHIN 'SWAP' .NE. 

R 'PAYUSR' - THE USER CURRENT*,* MG EAR TIME 

R 'SYSTIM' - TIME SYSTEM WAS fNlflAL*ZEO 

R 'BEGTIM' - THE LAST TIME *CUR$SR* BEGAN TO RUN 

R 'QUANTM' - MAXIMUM RUMNH* TIME AT LEVEL 

R 'MAXTIM' - USER RUNS AT SA UNTIL 'MAXTIM' 

R 'TBASE* - BASE TIME FOR C0MPMTIH6 •MAXTIM 1 

R 'PAYT1M' - LAST TIME A USER MAfc CHARGED FOR TIME 

R 'LEVTIM* * LAST T»ttE *CURUSR* DRUMMING AT CURRENT LEVEL 

R 'SWAP' - NON-ZERO qgStti TO RUN 

R 'NEWUSR* AS SOOiN AS IT CAN 

R 'MAXLVL' - THE MAXIMUM PRIORITY LEVEL<Q ... 'MAXLVL') 

R 'MINLVL' - THE MiHIMUM PRIORITY LEVEL ALLOWED 

R 'FULLVL* - I NIT. LEVEL FOR *MX£& *0 FULL CORE USER 

R 'EMPLVL' - INITIAL LEV&L FOR EMW CORE USER 

R 'FULLEN' - LENGTH F<» ElffRY At LEVEL •FULLVL* 

R 'PB» - Gl E€0 PER IND 

R 'QNTWAT' - QUANTM WAITING UM BEFORE LEVEL CHANGE 

R TO NEXT HIGHEST IH6U|ft4TY L 

R 'LEV INC* - AMOUNT PRIORITY, LEVEL IS INCREASED WHEN 

R USER RETURNS TO WORKING FftOM INPUT OR OUTPUT WAIT 

R 'INACTV - MAX, TIME INACTIVE BEEORE LOGOUT 

R 'HANGUP' - MAX. TIME BEFORE INACTIVE LINE IS HUNGUP 

R 

R COMMON VARIABLES REFERRED TO BY SCHEO. BUT 

R NOT SET OR CHANGED BY SCHEO. 

R 'BKGTIM* - TOTAL T 1 ME BACKGROUND MAS RUN 

R 'SWPSW' - NON-ZERO WHEW SUPERVISOR IS SWAPPING AND 

R COMMAND LOADING 

R 'PROBN(J)* - NON-ZERO WHEN USER J IS LOGGED IN 

R 'ADOPT(J)' - PROBN(J) .ANO. AOOPT(U) .E. XB, THEN 

R USER J IS ADOPTED 

R ' 

R SCHED. CALLS THE FOLLOWING SUBROUTINES 

R INITQ. - INITIALIZES QUEUES 

R HEDUSR. - RETURJ THE HEAD OF QUEUE USER 

R AT HIGHEST IfflN-EMPTY PRlQJMTY "LEVEL OR 

R DELQUE.(J) - DELETES USER J FROM QUEUES 

R ENDQUE.(J) - PLACES USER U AT END OF QUEUE LEVEL(J) 



m vmm m tmw ' * "* 
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R BEGQUE.U) - PLACES USER J AT BEG OF QUEUE LEVEL(J) 

R ILGG2.CN) - RETURNS INTEGER PART OF LOG TO BASE 2 N 

R I. (J) - CONVERTS FORWARD INDEX 'J* TO BACKWARD 

R INDEX FOR REFERRING TO MAD ARRAYS 

R INITIM. - INITIALIZE TIME ACCOUNTING 

R I NT I M. - USER 'U' LOGGED IN 

R OUTIM. - USER 'U' LOGGED OUT 

R CHARGE. (U,T) - CHARGE USER 'U' FOR TIME 'T' 

R GETOTL. - RETURNS THE TOTAL TIME SYSTEM HAS RUN 

R DELTIM.(T) - RETURNS DELTA 'T» - THE DIFFERENCE 

R BETWEEN 'GETOTL. ()' AND TIME 'T' 

R TIME 'T' IS ALSO SET TO GETOTL.(O) 

R CURTIM.(O) - RETURNS THE CURRENT TIME SINCE MIDNIGHT 

R OF DAY SYSTEM WAS INITIALIZED 

R MONSC1. ( EVENT , USER, ARG) MONITORS SCHED. 

R MONSC2. IS CALLED WHEN SCMED, CHANGES COMMON 

R PLOT1. (EVENT, USER, ARG) PLOTS SYSTEM ON ESL SCOPE 

R PLQT2. IS CALLED WHEN SCHED. CHANGED COMMON 

R 

EXTERNAL FUNCTIONCA, B, C) 

ENTRY TO SCHED. 

NORMAL MODE IS INTEGER 
R 
R.. SHORTEN LINKAGE, SETUP USER 

CALL PLOTTING ROUTINE . 

ASSUME COMMON WILL BE CHANGED, AND DISPATCH ON 'EVENT' 



INDEX, CALL MONITORING SUB., 



R.. 
R.. 
R 

EVENT - A 

USR - B 

I USER - I. (USR) 

ARG - C 

EXECUTE MONSC1. (EVENT, USR, ARG) 

EXECUTE PLOT1. (EVENT, USR, ARG) 

MONITR * CHANGE 

STATEMENT LABEL MONITR, RETURN, CHANGE 

TRANSFER TO EVNT( EVENT) 



: .» 
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R.. 'EVENT 1 .E. 0, INITIALIZE SQHEDUL IMG ALGORITHM FOR N USERS 
R.. INITIALIZE INDEPENDENT COMMON VARIABLES 
EVNT(O) MXUSRS - 31 

MAXLVL - 8 

MINLVL - 

FULLVL ■ 3 

EMPLVL - 2 

FULLEN « W96 

PB - 

QNTWAT « 3600 

LEVINC - 

QUANTM - 30 

TBASE - 

INACTV - 216000 

HANGUP - 7200 
R 
R.. INITIALIZE QUEUES AND TIME ACCOUNTING 

EXECUTE INITQ. 

EXECUTE IN1TIM, 
R 
R.. INITIALIZE TABLES 

THROUGH JLOOP, FOR J - 0, 1, J .G. UMAX 
JUSER - I. (J) 
JLOOP LINMUL(JUSER) - 1 



R 

R. 

R. 



SET BACKGROUND (USER 0) TO RUN 

USER IS ALWAYS IMPLICITLY AT tNO OF QUEUES 
SYSTIM - CURTIM.(O) 
STATUS(l,(0)) - 2 
SWAP * IB 
FIRST3 - IB 
BGMAX - 180 
TRANSFER TO CHANGE 
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R.. 'EVENT' .E, l< CLOCK INTERRUPT 
R.. ASSUME COMMON WJLL NOT Df CHANGED 
EVNT(l) MONITR - RETURN 

I CUR - I, (CURUSR) 
T » GETOTL.(O) 
R.. 00 THE FOLLOWING CHECKING EVERY 10 SECONDS 
R.. CHARGE PAYING USER FOR TfMt 
R.. MOVE LONG WAITING USERS UP IN PRIORITY 
R.. LOGOUT INACTIVE USERS, HANG UP INACTIVE LINES 
WHENEVER T ,G. CHECKT 
CHECKT - T +600 

EXECUTE CHARGE. CPAYUSR, DELTIM, (PAYTIM) ) 
THROUGH KLOOP, FOR K » 1, 1, K .G. UMAX 
WHENEVER K .E. CURUSR, TRANSFER TO KLOOP 
KUSER * l.(K) 

DELT « T - WATT IM( KUSER) t ..„,.,, 

WHENEVER STATUS(KUSER) .E. 3 .OR. STATUS( KUSER) .E. I 
WHENEVER OELT .6. QNTWAT .ANO. LEVEL(KUSER) .G. MINLVL 
MOJUTR - CHANGE 
EXECUTE DEL<|UE.(K) 
LEVEL(KUSER) - LEVEL(KUSER) - 1 
EXECUTE ,(K> 

WATTIMC KUSER) " T 
TIML£V(KUS£R) - 
END OF CONOmONAL 
OR WHENEVER PROBN(KUSER) »NE. • 

WHENEVER OELT .G. INACTV .AMD. LI NENOC KUSER) .E. 
MONITR - CHANGE 
NOT I ME< KUSER) * 2 
WATT I M( KUSER) • T 
END OF CONDITIONAL 
OTHERWi SE 

WHENEVER DELT ,G, HANGUP .AND. ADOPT(KUSER) .E. 
MQNITR « CHANGE 
NOTIME(KUSER) ■ * 
WATTIMCKUSERX • T ' 
END OF CONDITIONAL 
END OF CONDITIONAL 
KLOOP CONTINUE 

END OF CONDITIONAL 
R.. MOVE LONG RUNNING 'CURUSR 1 DOWN IN PRIORITY 

WHENEVER CURUSR .NE. .AND. T ,G. MAXTIM 
1 .AND. .NOT. SWAP 

MONITR - CHANGE 
EXECUTE DELQUE.C CURUSR) 
WHENEVER LEVEL(ICUR) .L. MAXLVL / 
1 LEVEL(ICUR) - LEVEL(ICUR) ♦ 1 

EXECUTE ENDQUE. (CURUSR) 
LEVTIM » T 
TIMLEV(ICUR) - 

MAXTIM - T ♦ TRUN. (CURUSR, LEVEL(ICUR)) 
END OF CONDITIONAL 
TRANSFER TO DECIDE 
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R 'EVENT' .E. 2, 'USR' ( ' I USER 1 ) CHANGER STATE 

r7. DISPAKH Qm'nEW STATE, l(^^ R|D^«T TRANSITtONS 

£VNT<2) ^ENEVER USR ;m. Q/TRAWSFtR TO StAtC*RlW 

TRANSFER TO RETURN 

r.. 'USR'C IUSER') WENT DEAD, EVENT 6 WILL t4QT OCCUR 
STATU) EXECUTE DELQUE.CU&R) 
STATUS* J USER) » i) 
TRANSFER TO DECIDE 

R 

R.. ' USR'C I USER') WENT DORMANT WHILE RUNNING 
R.. OR PUSHED QUIT BUTTON 

STAT(l) EXECUTE DELQUE.(USR) 

STATUS(IUSER) • I _„.„,. 

WHENEVER USR .E. CURUSR, TRANSFER TO DECIDE 

TRANSFER TO CHANGE 

R., 'USR'C I USER') TO BEGIN WORKING AFTER I/O WAITING 
R., OR ALARM CLOCK RETURN FROM DORMANT TO WORKING 

STATU) WHENEVER ST ATUSC1 USER) .GE. k .OR. STATUSC IUSER) .E. 1 
WHENEVER ST ATU5< IUSER) .NE. I 

WHENEVER L£VEL( IUSER) - LEVIM .Gt. MINLVL, 
1 LEVEL( IUSER) » LEVEL CHJSER) - LEV INC 

LEV - LEVELF.CLENGTHdUSEJUl ^ '. 

WHENEVER LEV .L. LEVEL( IUSSR), LEVEL< IUSER) - LEV 
TIMLEV(IUSER) • 
END OF CONDITIONAL 
EXECUTE ENOQUE.(USR) 
WATT I M( IUSER) - GETOTL.CO) 
STATUS (I USER) •» 2 
TRANSFER TO DECIDE 
END OF CONDITIONAL 
TRANSFER TO RETURN 

R 

R.. 'USR* ('IUSER') BEGAN WAITING FOR A COMMAND 

STAT(3) LEV - LEVELF. (LENGTH* IUSER) ) rt ., wltHf , lllMB , - , 
WHENEVER STATUSC IUSER) .E, 2 .QR. STATUSC I USER) .E. 3 
WHENEVER LEV ,G. LEVELUUSER) 
EXECUTE DELQUE.(USR) 
TRANSFER TO COMAND 
END OF CONDITIONAL 
OTHERWISE 
COMANO LEVELUUSER) - LEV 

EXECUTE ENDQUE.(USR) 
TIMLEV(IUSER) - 
WATTIM(IUSER) -GETOTL.(O) 
END OF CONDITIONAL 
STATUS (I USER) - 3 
TRANSFER TO DECIDE 
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R.. 'USR' (' I USER*) ENTERED INPUT WAIT 
STATU) WHENEVER STATUS( I USER) ,E. 2 
EXECUTE DELQUE.(USR) 
STATUS(IUSER) » 4 
TRANSFER TO DECIDE 
END OF CONDITIONAL 
TRANSFER TO RETURN 
R 

R.. 'USR'ClUSER') ENTERED OUTPUT WAIT 
STAT(5) WHENEVER STATUS( I USER) .E. 2 
EXECUTE DELQUE.(USR) 
STATUS( I USER) - 5 
TRANSFER TO DECIDE 
END OF CONDITIONAL 
TRANSFER TO RETURN 
R 

R.. THE NEXT THREE EVENTS ALWAYS OCCUR IN SEQUENCE 
R.. WHEN CONTROL IS TRANSFERRED FROM 'OLDUSR' TO 'NEWUSR' 
R.. AS A RESULT OF 'SWAP' BEING SET NON-ZERO. 
R.. 'OLDUSR' DOES NOT PAY FOR HIS DUMP, UNLESS 
R.. 'NEWUSR' IS OF EQUAL OR LOWER PRIORITY. 
R.. 'NEWUSR' ALWAYS PAYS FOR BEING RESTORED EXCEPT 
R.. BACKGROUND NEVER PAYS FOR DUMP OR RESTORE. 
R 

R.. 'EVENT' .E. 3, SAVING OF 'USR'ClUSER') IS BEGINNING 
R.. EVENT 3 MAY BE CALLED FOR ANY OF THE FOLLOWING: 
R 1. FREEING UP CORE B BECAUSE 'CURUSR' EXTENDED SIZE 
R 2. FREEING UP CORE A DRUM BUFFERS FOR SWAPPING 
R 3. DUMPING 'OLDUSR' 

R 4. DUMPING OTHER USERS TO MAKE ROOM FOR 'NEWUSR' 
BOOLEAN SWPSW, FIRST3, DMPOLD, SWAP 
EVNT(3) WHENEVER SWPSW 

WHENEVER FIRST3 
FIRST3 = OB 

EXECUTE CHARGE. (PAYUSR, DELT IM. (PAYT IM) ) 
WHENEVER LEVEL( I. (NEWUSR)) .GE. LEVEL ( I . (OLDUSR) ) 
1 .AND. OLDUSR .NE. .OR. NEWUSR .E. 
PAYUSR * OLDUSR 
OTHERWISE 

PAYUSR » NEWUSR 
END OF CONDITIONAL 

TIMLEVd. (OLDUSR)) - Tl MLEV( I . (OLDUSR) ) + DELT I M. (LEVT IM) 
OTHERWISE 

EXECUTE CHRGSW. 
WHENEVER USR .E. OLDUSR 

DMPOLD » IB 
OR WHENEVER DMPOLD .AND. USR .NE. OLDUSR 
1 .AND. NEWUSR .NE. 
PAYUSR - NEWUSR 
END OF CONDITIONAL 
END OF CONDITIONAL 
END OF CONDITIONAL 
TRANSFER TO CHANGE 



IPtfPIPflliW^ iPH«WJP.»WH ' 



r 
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R.. 'EVENT 1 *E. * # RESTOWNO OF •NEWUS* 1 IS BEGINNING 
EVNTU) EXECUTE CHR6SW. 

WHENEVER NEWUSR .E. 
PAYUSR * OLDUSR 

OTHERWISE 

PAYUSR - NEWUSR 

END OF CONDITIONAL 

WHENEVER STATUSC I. (OLDUSR) ) .E. 2, 
1 WATTIJ4<l.(OLOUSR)) « GETOTL.(Q) 

CURUSR - NEWUSR 

TRANSFER TO CHANGE 
R 

R.. 'EVENT' .E, 5, 'NEWUSR' BEGINS RUNNING AFTER RESTORE 
EVNT(5) EXECUTE CHARGE. (PAYUSR, DELTIM).(PAVTI«» 

PAYUSR - NEWUSR 

WHENEVER STATUS (I. (NEWUSR)) .E. 3, STATUS( I . (NEWUSR)) - 2 

BEGTM » GETGTL.(O) 

LEVTIM - BEGTJM 

MAXT I M .- - BEGT I M ♦ TRUN . (NEWUSR, LEVEL (I . (NEWUSR) ) ) 
1 -TIMLEV( I. (NEWUSR)) 

SWAP - OB 

FIRST3 -IB 

OMPOLO - UB 

TRANSFER TO DECIDE 
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R.. 'EVENT' .E. 6, »USR*< ' J USER' ) CORE IS OF LENGTH 'ARG' 
R.. 4UST BEFORE ENTER IN® WAIT HM5 COMMAND 
R.. OR LENGTH CHANGED WHILE RUNNING 
EVNT(6) LENGTH(IUSER) - AR0 

WHENEVER USR .E. GURMSR 

LEV - LEVELF.(LENGTHCIUSER)) 
WHENEVER LEV «G. LEVEL( IUSER), 
1 MAXTIM - BEGTIM + TRUN.CCURUSR, LEV) - TIMLEVC IUSER) 
END OF CONDITIONAL 
TRANSFER TO CHANGE 
R 

R.. 'EVENT' .E, 7, OPERATOR SET KEYS TO 'ARG' 
EVNTC7) KEYS - ARG 

BACKGR - ARG 
TRANSFER TO DECIDE 
R 

R.. 'EVENT' .E. 8, 'USR' (' IUSER' ) LOGGED IN PROPERLY 
EVNT(8) LINMUL( IUSER) - ARG 
EXECUTE I NT I M. (USR) 
TRANSFER TO CHANGE 
R 

R, . 'EVENT' .E. 9, 'USR' ( ' I USER' ) LOGGED OUT 
EVNTO) EXECUTE OUTTIM.(USR) 
TRANSFER TO CHANGE 
R 

R., 'EVENT' .E. 10, IS 'NEWUSR' STILL RUNABLE 
EVNT(IO) WHENEVER STATUS* I .(NEWUSR)) .E. 2 

1 .OR. STATUS( I. (NEWUSR)) .E. 3, TRANSFER TO RETURN 
SWAP - OB 
TRANSFER TO DECIDE 
R 

R.. 'EVENT' ,E. 11, 'USR'C IUSER') DIALED UP COMPUTER 
EVNT(ll) WATT IM( IUSER) • GETOTL.(O) 
NOT I ME( IUSER) - 
TRANSFER TO CHANGE 
R 
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R. . COMMON EXIT FROM SCHED. 
R.. DECIDE IF IT IS TIME TO RUN A MEW USER 
R 

R.. NO DECISION WHILE SWAPPING 
DECIDE WHENEVER SWAP, TRANSFER TO MONITR 

R 
R.. CHECK IF BACKGROUND NOT MEET \ NG GUARANTEED PERCENTAGE 

WHENEVER BKGTrM .L. (PB/1Q0.) * GETOTL.CO) 
1 .AND. CURUSR ,NE. 0, BACKGR * 1 

U « HEDUSR.(Q) 

WHENEVER BACKGR ,NE. .OR. KEYS ,NE. , U - 
R 
R.. RUN USER 'U' IF 'CURUSR* HAS RUN AS LONG AS , U* WOULD 

WHENEVER U .NE. CURUSR .AND. 

1 (PREMPT.(TRUN.(U, LEVEL< I .<U>>) ) .OR* CURUSR ,E. 0) 

2 .OR. STATUS( I .(CURUSR)) .NE. 2 .OR. BACKGR .NE. 
MONITR - CHANGE 

SWAP - XB 
NEWUSR - U 
OLDUSR • CURUSR 
BACKGR - 
END OF CONDITIONAL 
R 

R.. CALL MONSC2. IF COMMON CHANGED, ELSE JUST RETURN 
TRANSFER TO MONITR 
CHANGE EXECUTE MONSC2. 

EXECUTE PLOT2. 
RETURN FUNCTION RETURN 



^W-WMW^J .. ,,.^ ****^^^ . .i nHI i.ii f .ii j iii l i. W .) Hl i i ■ 
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R. . INTERNAL FUNCTIONS 
I TRUN R., 'TRUN 1 -COMPUTES RUN TIME FOR USER 'DU' AT LEVEL 'DL' 

I . INTERNAL FUNCTION TRUN.fttU, DL) ■ 

i 1 TBASE ♦ LINMUL<I.(DU)) * OUANTM * 2 . P. DL 

R 
LEVELF R.. 'LEVELF' - COMPUTE PRIORITY LEVEL BASED ON LENGTH 'LEN' 
INTERNAL FUNCTION LEN) 
ENTRY TO LEVELF. 
WHENEVER LEN .GE. FULLEN 

L - FULLVL 
OTHERWISE 

L - EMPLVL + ILOG2.(LEN/<FULLEN/(2 .P. (FULLVL-EMPLVD) )) 
I END OF CONDITIONAL 

FUNCTION RETURN L 
END OF FUNCTION 
: R 

PREMPT R.. 'PREMPT* - IS TRUE IF PREMPTION IS PERMITTED 
R.. BASED ON TIME INTERRUPTER WILL RUN 'I NT RUN' 

BOOLEAN PRfMPT. 

INTERNAL FUNCTION PREMPT. (I NT RUN) « 
1 INTRUN .L. GETOTL.(O) - BEGTIM 

i R 

' R.. SUBROUTINE TO CHARGE SWAPPING TIME 

CHRGSW R.. FOREGROUND PAYS FOR BACKGROUND SWAP UP TO 3 SECONDS 
j INTERNAL FUNCTION 

ENTRY TO CHRG SW. 
TDEL » DELTIM.(PAYTIM) 

WHENEVER OLDU$R .E. .ANDV TDEL .G. BGMAX 
EXECUTE CHAflGE.CPAYUSR, BGMAX) 
EXECUTE CHARGE. <tf, TOEL-BGMAX) 
OTHERWISE 

EXECUTE CHARGE. C PAY USR, TDEL) 
END OF CONDITIONAL 
FUNCTION RITURN 
END OF FUNCTION 
! 



£»•»•'«?. 
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R.. COMMON VARIABLES 
VECTOR VALUES COMR4.C 
VALUES 
VALUES 

values 

VALUES 
VALUES 



VECTOR 
VECTOR 
VECTOR 
VECTOR 
VECTOR 
R*. •MXUSRS' 
DIMENSION 
DIMENSION 



C$M*U 
UMAX - 
UMAX - 

MAXLV ■ 

MAXLV - 

MOST BE 

FAKE (32 5 61) 

DUMMY0<5i), 



• 32561 
- 32551 

51 
10 
ID 
.LE. 51 



AND r MAXt¥L* MUST BE .LE. 10 



DIMENSION TIMLEV(Sl) 
0,1 MENS I ON WATT I M( 51) / 
D I ME NS I ON PLl ST C73 1, 
TOTLEV(O) 
DUMMYftCSi), 
TAfc<51>* 
TUM51I* 
IT (ME 

LINEN0(51>, 
FULLSWC5U 
UOWAimi), 
WTIMESUl) 
UNITID(51) # 
IU*£StSU* 
ULltfE<5D* 



STATUS<51>* LENGTHCS1), LEVELC51) 



DIMENSION 

DIMENSION 

DIMENSION 

DIMENSION 

DIMENSION 

DIMENSION 

DIMENSION 

DIMENSION 

DIMENSION 

DIMENSION 

DIMENSION 

DIMENSION 

01 MENS ION 

DIMENSION 

DIMENSION 

DIMENSION 

PROGRAM 

PROGRAM 



LINMUUO), 
ULIST(O)* 

TAK51)* 
TU1CS1), 

PRQBNCS1), 
LfNC*(5lV 



DUMMY2C735 
DUMtt 

TA2^|54X* 

iviisiy, 

N0T1MM51) 

RRQUNai) 

MA1^£CW # 



ENPPTRUO) 

TA3t$l) 
TU3(5l) 



RSPQNSC51) 



RWOROSC5U* WMOROStSl), RT1ME$(51) 




MUNGSVW51) 

fOD(Sl) 

UCHAM<51> 



MfrTisi) 



, OUTFSWC51J> gig 

UL<NCTt5ir, 
AWAKE(5l** TIMINC<5D* Cf 
0*PRGB<5U* OKPROG(Sl)* 
DUMMYCU7)* P8UFF<0) 

DUMMYE<*6S*V BdUnGU, UUNJ«rGCV65), DBUF2C0) 
COMMON FAKE 
COMMON ENBWD 



m&h 



linmul* 

ENDPTR* 
UPDATED 
TA1* 
TU2* 



PROBN* 




mmi, TIMLEV 
4*£m* OUST 

ACCOUNTING 



TA3* 
TUfc* 



R.. COMMON ARRAYS SET AND CHANGEO AY 

PROGRAM COMMON DUMMV#* STATUS* Lfi 

PROGRAM COMMON WATTm* 

PROGRAM COMMON DUMMY %* 
R.. TABLES SET BY LOGIN* 

PROGRAM COMMON DUMMY 6* 

PROGRAM COMMON TU1* 

PROGRAM COMMON NOT t ME 
R«. TABLES SET BY LOGIN 

PROGRAM COMMON ITIME* 
R,. USER OPT IONS (CHECKED 

PROGRAM COMMON LINE NO, 
R.. TABLES FOR DISK MONITORING 

PROGRAM COMMON UOtfAIT, RNORDS* WORDS, RTIMES* WTIMES 
R.. OTHER USER TABLES 

PROGRAM COMMON UNIT ID, 

PROGRAM COMMON OUTPSW, 

PROGRAM COMMON UCLOCK, 

PROGRAM COMMON ADOPT, GKPttOt* OKPROS, COMFSW 
Rv. COMMON VARIABLES SET AND CHANGED BY SCHfOL, ONLY 

PROGRAM COMMON MXUSRS* CURUSR, OLOUSR, NEWUSR, PAYUSR 

PROGRAM COMMON SYSTIM* BEGTIM* OUANTM* MAXTIM* TBASE 



PROGN 
BY CLKlNt AND TCORRO) 
LI NCR, MANUAL* RSPONS* 



COMMND, 
COMCTR, 
UCHARG, 



INTRSW, 

100* 
AWAKE, 



HUNGSW, 

UL1NE* 

THWWC* 



TA«i 
UTIME 



FULLSW 



• \ I NES 

•JNCT 

f.OCON 
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PROGRAM COMMON 


PAYTIM, LEVTIM, 


SWAP, 


MAXLVL, 


MINLVL 


PROGRAM COMMON 


FULLVL 








PROGRAM COMMON 


EMPLVL, FULLEN, 


PB, 


QNTWAT 




PROGRAM COMMON 


LEVINC, INACTV, 


HANGUP 






R.. VARIABLES SET BY LOGIN 








PROGRAM COMMON 


SPRQBN, SPROGN 








R.. OTHER VARIABLES 








PROGRAM COMMON 


USER, DATE, 


DATEYR, 


TIMNOW, 


NUSERS 


PROGRAM COMMON 


SWPSW, COMSW, 


TOTTIM, 


BKGTIM, 


SWPTIM 


PROGRAM COMMON 


COMTIM, USRWAT, 


SWPWAT, 


COMWAT, 


AUTOND 


PROGRAM COMMON 


CLKTIM, MXLINE, 


NWORDS, 


STOPSW 




PROGRAM COMMON 


DSKLOC, BASEAD, 


WAIT, 


DUMMY 8, 


READY 


PROGRAM COMMON 


BUFULL, DUMMYC 








PROGRAM COMMON 


PBUFF, DUMMYE, 


DBUF1, 


DUMMYG, 


DBUF2 


R.. USER MACHINE 


CONDITIONS STATUS TABLE 






R.. (NOT REFERRED TO BY MAD PROGRAMS) 






END OF FUNCTION 
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5. Flow Charts of Main Control and Trap Processors. 



Introduction. 

This section consists of five flow charts of Main 
Control , the clock and protection trap processors, and the 
nodule RSTCPU. These flow diagrams are to help provide a 
temporary bridge between complete lack of Information about 
these modules and the assembly listings themselves. 




Call SCHEDL 
(Event 10) 
last chance 
to set 
SWAP j 



T 



t'f ^WAP « qZZl 7WT 

I no 




LRSTCPU 



Is NEWUSR In 
"Waiting Command" 



I 



yes 



no 




Dump USER 
Restore NEWUSR 



? 



Call SCHEDL 
(Event 5) 




Figure 5.1 — Cycle entry of Main Control. 
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<£mPR0C^ 



Is command 
on disk 



~w 



yes 



Is user 
NEWUSR 



"F" 



1£S- 



Dump USER 
Restore NEWUSR 



T 



CaU SCHEDL 
(Event 5) 



T 



Is command 
In core B 



Jno 



Transfer to 
core A command 





Is user 
- NEWUSR 



Jno 



yes 



Insure 
Enough Room 
for command 
(FREEUP) 



Dump USER 
Restore tables 
for NEWUSR 



T 



Load command 
file Into 
core B 



I 



Reset user 
machine conditions 
and active f lies. 



T 



Call SCHEDL 
(Event 5) 




Figure 5.2 -- Command Processing In Main Control 
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200 ms 
clock 
trap 



i 



Save 

Machine 
Conditions 




XKINP. 



*MNES(,I) f 
* no 



OUTPSW(I ) f 
7f&— 



Is 



STATUS(I) - 5 

I 



yes 



Call SCHEDL 
(Event 2) to 
change STATUS 
to Working (2) 



I 




CKEND. 



Repeat for 
d 



Jtf 



one 



TC00RD 



get tUHEStH 
t for Input 
Set OUTPSW(I) 
- If buffer 
is empty. 



JtSi 



JtSS. 



Is ILINES(I) 

I " 



Is STATUS(I) 
Of 1 



I 



yes 



Is line a 
c ommand 



y«* 



type WAIT 
move command 
line to 
command buff 
Call SCHEDL 
(Event 2) to 
set STATUS 

12L2U -* 

.. .. . ' ^ 



( I t s the user 
Index In the 
polltm* ioop.) 



Jt£L 



Process 
Quit 



HO 



J&. 



1 



type 

■— Is not 



jM^vi input 
Una to 
Inffi t buffer 



Call SCHEDL 
(Event 



HEDTU 



JUmtm 



Was tflM> 
from Hem, te 



ITWfl'-Xmli 



Move; 

machl 

£2041 




Return to 
Interrupted 
Program via 
Common Exit 



Figure 5.3 — The Clock Trap Processor. 
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Is SWAP t~T] TeT 

I no 

Did user interrupt?! yes 




CYCLE 



yes 


* 




Is he expecting 
Interrupts? 


no 




1 yes 



Type: 

"No Action" 



Save current ILC, 

Reset ILC for 

I nterrupt 



T 



Drop user Interrupt level 



1 


r 




Check for HTR 
at ILC location 


f 


1 




Restore Machine 
Condi tlons 


1 




Go to user. 





J 



Type new level number 



yes 



Type "PROGRAM 
STOP AT 0000" 




JNDUSR. 



Figure S,k — Flow diagram of RSTCPU (Restart user.) 
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Protection 
Mode 
violation 




Save user 



mach I ne 
conditions 



T 



Does user's 
ILC violate 



| no 



Pick up 

violating 

Instruction 



1 



G 



s It a TIA 



t 



yes 




.PCKSUB. 



Pick up word 
at address of 
T.IA 



T 



Is this a 

ffMt>ro4t!n< 



iytipj 
lyes 



no 



Transfer to 
user subroutine 
( In protection 
section.) 



yes 




na 



Is user 
Background 



yes 




no 



■J^PTERR^ 



Type — Is 



T 




PTERR 



Figure 5.5 — Tie Protection trap processor. 
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6. The Disk Control Module. 

I ntroduction . 

As mentioned earlier, there are four distinct uses of 
the disk and drum memories: 1) temporary storage of working 
programs which do not fit Into memory; 2) storage of 
supervisor command programs; 3) storage of user programs and 
data; and U) scratch pad storage by user programs. These 
uses have enough in common, however, that a single interface 
program, the Disk Control Module, handles al 1 use of these 
memories. Calls from the supervisor are not distinguished 
from calls from a user program. In particular, the 
supervisor does not attempt at any time to use the disk 
except through the disk control module. 

In addition to this disk control program, there Is a 
pair of disk load and disk dump programs which are used for 
off-line input to and output from the disk memory. These 
routines are not part of the supervisor and in fact do not 
presently operate while the time-sharing system is running. 
The dump routine copies the contents of the disk memory onto 
tape for backup purposes, and processes users' request cards 
to produce printed and punched copies of their personal 
files. The load routine copies a tape onto the disk to 
re-Initialize the time-sharing system, and also processes 
users' request cards to add files (consisting of punched 
cards) to the disk. 

The Disk Control Routines. 

A complete, though slightly out-of-date, technical 
description of the current disk control module may be found 
In the Computation Center Memo CC-196, July 11, 1962. A new 
disk control module Is currently being designed. 

Lpad,inK and Dumping, the PIsK. 

A complete technical description of the two programs 
LDEDT (disk load editor) and DPF.DT (disk dump editor) may be 
found in the Computation Center Memo CC-108, May 9, 1963. 
An operational description Is provided In Memo CC-212. 

Disk Routine Tables. 

The format of the master file directory Is shown In 
figure 6.1. Figure 6.2 Is the layout of the user disk 
status table as it appears in the disk routine and as it 
appears on the drum or disk when a user leaves core memory. 
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Cha I n 


word 


Programmer 
Number 


Problem 
number 


Track 
Quota 


Address of user 
file directory. 


_^y^ " 



two -word 
entries 



etc. 



(The first track of the M.F.D. Is stored on track of 
Module 1.) 

Figure 6.1 — Format of Master File Directory 



UTABLE 



TRCNT 
QUOTA 
FILNR 
UFILTR 



chain word 



document 
nnmhftr 



tracks 
"*»d 



Primary file name 



Secondary file name 



Mode 



file 
m » mh » r 



Date last 
used 



track 
address 



number of 
tracks 




count of tracks used 



track quota 



HIstorlcal-not used 



Pointer to current 
track usage table track 



J»-word 
entries 



Current 
track of 
user's 
file 

directory 
(1*66 wds.) 



Figure 6.2 — The Disk Status table, total slze / 551 words, 
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FFDRTR 
TPONLY 
CHNGD 
ACTTBL 



DEFMOD 

ASNMOD 

UFLGS 

TRKOVR 

SVUFDT 



Location of first 
track usage table track 
Historical not used 



Switch — UFD has been 

changed 

Primary file name 



Secondary file name 



Buffer addresses 



Track to be written next 



Word count 



Word count 




Logical Module Assignment 



Historical 
not used 



Error Flags 



Amount track quota Is 

exceeded 



User file directory 

address 



5 words 



Figure 6.2 (cont.) The User disk status table, 
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7. Description of Entry points and Cross Reference Table 

Introduction. 

An invaluable aid in studying the operation of any 
single module or subroutine within a module is a thumbnail 
sketch of each of the subroutines which It calls. If such a 
sketch Is available/ attention can remain within the module 
being studied; the reader need not have a detailed 
understanding of how the subroutine works to comprehend the 
program which calls the subroutine. Also, when looking at 
the thumbnail sketch of a subroutine to figure out what it 
does, it is useful to have some idea of which other modules 
also call this subroutine; this allows one to establish the 
"place" within the system of the subroutine. In this 
section, then, Is listed each entry point of each module, a 
brief description of what the entry point does, and a list 
of all modules of the supervisor which call this entry 
point. The information In this section pertains to version 
"1A1" of the time-sharing supervisor. All program sizes are 
given In octal . 



Module ADPI 

Function: 7750 I/O adapter module. 

Size: 23<»0 words. 



Entry Points: 

WRTELY Subroutine to write a line on a 
teletype. 

RDTELY Subroutine to accept characters 
from a teletype, 
callers: CHNE (ETRAP) 
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Module: 



AP75 



Function: 



Handles 7750 buffers, 



Size: 



kk7 words. 



Entry Points: 



WT7750 Write output on 7750. 
callers: ADPI, HIGH 



Module: 



CHNE 



Function: 



Hardware routine to drive data channel E 
(7750 and teletypes). Contains 7909 
channel programs. 



Size: 



363 words. 



Entry Points: 



CHANLI Subroutine to Initialize 7750 and 
channel E. 
callers: CTRL, MAIN 

WR7750 Subroutine to transmit data to 
7750. 
callers: AP75 

ETRAP Channel E data channel trap entry, 
callers: MAIN, channel 
E data channel trap. 

ST0PE Shut down channel E for hlph-speed 
drum. 
callers: ST0R 

STARTE Restart channel E after ST0PE 
has stopped It. 
callers: ST0R 
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Module: 



CL0C 



Function: 



Clock trap processor module. 



Size: 



1377 



Entry Points: 



STCL0C 

CLKINT 
GETOTL 
ADDTIM 



Subroutine to start up Interval 
timer clock, 
callers: CTRL, MAIN 

Interval timer trap entry. 
callers: MAIN; clock trap. 

Get time system has been running, 
callers: SCHftf 

Update time used, 
ca 14#rs t" CUti ST0R 



Module: 



C0MC 



Function: 



Miscellaneous subroutines. 



Size: 



1*6 



Entry Points: 



ENKEYS 



STOP IF 



C0MCHK 



SETUSR 



Subroutine to enter console keys 
of Interrupt to CTSS. 
callers: CL0C, CTRL, PMTA 

Subroutine to stop If key Ik Is 

down* 

callers: PMTA, RTRN 

Subroutine to search command 

directory for command in logical 

AC. 

callers: CL0C, CTRL 

Subrout lite to establ I sh cur rent 

user as a disk user. 

callers: CTRL, L0GA, PMTA, SAVC 

ST0R 



c 
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• 




BR0OM 


Scan adaption system. 

callers: CL0C, TC0R, PMTA, RDFX, 

L0GA 




' 




SWEEP 


Continue BROOM scan. 

callers: CL0C, TC0R, PMTA, RDFX, 

L0GA 




' 


Module: 


C0MD 






*>- 


Function: 


The command directory. 




*.- ."f ■ ** 


Size: 


172 






■ ■ 

4 ' ' 


Entry Points: 


Cf MM R 


Entry to command directory 

control word. 

caller: C0MC (C0MCHK) SCHED 




to 




FILE 

L0GIN 

ENDL0G 


Direct entry; to FILE entry In 
command directory, 
callers: CL0C 

Direct ei^tryto L0GIN entry In 

cownand directory. 

callers: CL0C, CTRL, PMTA, ST0R 

Direct entry to ENDL0G entry in 
command directory, 
callers: CL0C, CTRL, L0GA 








START 


Direct entry to START entry in 
command directory. 
- callers: GL0C 




- 




TFILE 


Direct entry to TFILE entry in 
command directory, 
callers: CL0C 




; • 


Module: 


C0NV 








Function: 


Conversion 


routines. 






PUPPPif^ 
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Size; 



2U68 



Entry Points: 



CTIME Subroutine to convert time In 60th 
to BCD 1/ 10th minutes, 
callers: 10GA, IJM5B 

TCTIME Subroutine to convert time In 60th 
to BCD In .01 hours, 
callers? L0GA, PMTA 

DTBC Subroutine to convert decimal to 
binary. 

callers* £#MCiSETUSR), UGA, L0GB, 
0NLN, PMTA 

BTDC Subroutine to convert binary to 
decimal . 
callers: L0GA, PMTA 

OTBC Subroutine to convert octal (BCD) to 
binary, 
caller: 0CTC 

BT0C Subroutine to convert binary to 
octal BCD. 
callers: 0CTC, PMTA, ST0R, RTRN 

RDYTIM Subroutine t^ifotain user command 
time used, to be typed wl th the 
"ftEAaY" comment, 
call art: CL0C, CTRL 



Module: 



CTRL 



Function. 



Main control module. 



Size: 



1160 



Entry Points: 



CHNC0M Entry to pick up next program- 
Initiated commend If any. 
callers: 0CTC, PMTA, SAVC 

NEWC0M Entry to set up new command 
for user, 
callers: PMTA 
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C0LD Entry to restart system after 
XEC loop, etc. 
callers: EDBfiC PANIC), MAIN 

DEAD Entry to place current user In 
"DEAD" status, 
callers: L0QA, PMTA, SAVC, ST0R 

ENDUSR Entry to set user status and type 
ready, 
callers: 0CTC, PMTA, RTRN 

ENDC0M Entry at end of command - ready 
not typed, 
caller: L0GA, PMTA 

CYCLE Entry to check for more work to do. 
caller: CL0C, PMTA, RTRN 

CKQUIT Subroutine to find If current 
user has pushed "QUIT" while 
In supervisor, 
caller: PMTA, RTRN 

ILLC0M Entry after Illegal sequence 
of commands* 
caller* 0CTC, SAVC 



Module: 



DCER 



Size: 



2168 



Entry Points: 



EPRINT On-line print subroutine (saves 
channel A), 
caller: CHNE, DSKI, ST0R 

ALLSAV Subroutine which saves all basic 
machine conditions, 
callers: CHNE, DSKI 

ALLRST Subroutine which restores all 
basic machine conditions, 
call Off: CHNE, DSKI 
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Module: 



DSKI 



Function: 



Disk control module 



Size: 



11506 



Entry Points: 



.DINIT Initialize disk routine, 
caller: MAIN 

.OPEN Sign user on to disk, 

callers: C0MC<SETUSR), CTRL, 
L0GA, MAIN, PMTA, SAVC 

.CLOSE Remove user from disk file, 
callers: L0GA, L0GB, PMTA 

.ASIGN Initialize writing a new file. 

callers: L0GB, PMTA, SAVC, ST0R 

.APENO Add to end of an old disk file, 
callers: L0GB, PMTA, SAVC 

.WRITE Write data with a disk file. 

callers: L0GB, PMTA, SAVC, ST0R 

.FILE Terminate writing of a file. 

callers: L0GB, PMTA, SAVC, ST0R 

.RELRW Open a file for relative 
read/write, 
callers: L0GB, PMTA, SAVC 

.SEEK Initialize a disk file for 
reading. 

callers: CTRL, L0GB, PMTA, 
SAVC, ST0R 

.READ Read data from a disk file, 
callers: CTRL, L0GB, PMTA, 
SAVC, ST0R 

.ENDRD Terminate reading from a disk 
file 

callers: CTRL, L0GB, PMTA, 
SAVC, ST0R 

•DLETE To delete a disk file and Its 
tracks, 
callers: PMTA, SAVC 
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.CTEST Check If a disk channel Is In 
operation, 
(not used.) 

.GTFLG Pick up error or control flags, 
callers: PMTA 

.SETDU Set current disk user. 

callers: CTRL, L0GB, MAIN, 
PMTA, SAVC, ST0R 

.STATL Get location of disk user status 
tables, 
callers: MAIN 

.FILDR Read a track of user file 
directory, 
callers: PMTA 

.UPDAT Update user file directory 
onto disk, 
callers: PMTA, SAVC 

.DFINE Define a new logical module 
number, 
(not used.) 

.RESET Reset all files In active status, 
callers: CTRL, PMTA, SAVC 

.FSTAT Obtain Information about a file, 
callers: CTRL, PMTA 

.SETAB Set memory switches for A or B. 

callers: CTRL, L0GB, MAIN, PMTA, 
RTRN, SAVC, ST0R 

.RDWAT Read out and reset channel 
waiting time, 
callers: CTRL, SAVC, ST0R 

.CHECK Watt until all disk activity Is 
finished, 
callers: ST0R 

.STKER Set error return on disk track 
error. 

callers: C0MC(SETUSR), CTRL, 
L0GA, L0GB, MAIN, ST0R, RTRN 

.ERASE Delete a file from directory, 
but leave Its tracks, 
callers: PMTA, ST0R 
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.GETDS Get status of active disk files, 
callers: SAVC 

.RENAM Change name or mode of a file. 
caller: PMTA 



Module: 



EDBG 



Function: 



System debugging aids 



Size: 



76i» 



Entry points: 



PANIC Entry to take a panic dump of 
both cores. 

callers: Console operator's 
restart: MAIN 

ADUMP Subroutine to dump memory A. 
caller: CL0C 

BDUMP Subroutine to dump memory B. 
caller: CL0C 

TRACE Subroutine to print out a trace 
of all traps, 
caller: CL0C 



Module: 



HIGH 



Function: 



High Speed line adapter 



Size: 



252 



Entry Points: 



RDHIGH Read high speed line, 
caller: ADPI 

WRHIGH Write high speed line, 
caller: ADPI 
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Module: 



L0GA, B, C 



Function: 



Login and logout commands and associated 
subroutines. 



Size: 



A 1713 
B 1206 
C 131 



Entry Points: 



LOGIN. TSS login command. 
caller: PMTA 

L0GERR Entry in case of error setting 
up user's file directory, 
callers: C0MC(SETUSR) 

ENDLG. TSS Automatic logout entry, 
caller: C0MDIR 

L0G0UT TSS logout command. 
caller: C0MDIR 



Module: 
Function: 
Size: 
Entries: 



MAIN 



Main Program 



2205 



(MAIN PROGRAM) Initialize system, set up trap 
returns, start system running. 



Called By: System loader 



Module: 
Function: 



MTRA 



TSS system statistics collector. 
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Size: 



6 (Dummy not presently used) 



Entry Points: 



M0NITR Entry to put away statistics, 
caller: CL0C 

EREAD Entry to obtain collected 
statistics, 
caller: PMTA 



Module: 



0CTC 



Function: Octlk / Octpat, and Octtra commands 



Size: 



200 



Entry Points: 



0CTLK: TSS 0CTLK command for core B. 
caller: C0MDIR 

0CTPAT: TSS 0CTPAT command for core B. 
caller: C0MDIR 

0CTTRA: TSS 0CTTRA command for core B. 
callers: C0MDIR 



Module: 
Function: 



0NLN 



On-line device manipulators for supervisor 



Size: 



i»20 



Entry Points: 



CL0CIN Read data and time from chronolog 
clock, 
callers: L0GA, MAIN 

PRINT Print 72 character line on-line, 
callers: CTRL, L0GA, MAIN, 
PMTA, RTRN, ST0R 



CTSS Technical Notes 



PAGE 71 



PUNCH Punch a card on-line, 
caller: L0GA 



Module: 



KLUD (PL0T at Computation Center) 



Function: 



Channel D 1/0 Adapter. 



Size: 



2161 at Center, 7173 at MAC 



Entry Points: 



PL0TS Plot statistics on 709U scope 
(center), 
caller: CL0C 

DSC0PE Display Information on ESL scope, 
caller: PMTA 

DTRAP Channel D trap entry. 

callers: MAIN, channel D data 
channel trap. 

DDTRAP Direct data trap entry, 

callers: MAIN, direct data trap, 

ST0PD Stop data channel D for High 
Speed Drum. 
Caller: ST0R 

STARTD Restart data channel D after 
High Speed Drum, 
caller: ST0R 



Module: 

Function; 

Size: 

Entry Points: 



PMTA 



Protection trap processor, 



51UU 



PTRAP Entry on protection mode trap, 
callers: MAIN; Protection mode 
violation. 
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BKSERV Entry to service background 
(requested by Keys), 
caller: CTRL 

ERR0R Entry to comment after a disk 
error, (not used) 

nPRINT Entry to print out a disk error 
on-1 Ine. 
caller: MAIN 

DERR Entry to process a disk error, 
caller: MAIN 

USERER To process disk track error for 
user, 
callers: CTRL, RTRN 



Module: 



RFLX 



Size: 



2705 



Entry Points: 



RDFLXA Entry for a user to obtain a line 
from common Input buffer, 
caller: PMTA 

ENTLIN Entry for supervisor to add a 
line to common Input buffer. 
callers: CL0C, PMTA 

RSSRB Entry to reset all input lines 
for this user, 
callers: CL0C, CTRL, PMTA, TC0R 

RSSWB Entry to reset user's output 
lines. 

callers: C.L0C, CTRL, L0GA, 
TC0R 



Module: 



RTRN 



Size: 



2«il 
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Entry Points: 



RSTCPU Entry to return to user program, 
callers: CTRL, L0GA, MAIN, 
PMTA, SAVC 

CMEXIT Entry to return to Interrupt 
program. 

callers: CHNE(ETRAP), CL0C 
DSKI, PL0T, UTRP 

CMXRTN Cell containing return location, 
callers:* EDBG(TRACE) 

L0AP.U Cell containing IRfc. 
callers: EDBG(TRACE) 



Module: 



SAVC 



Function: 



Save, restore, resume and start commands. 



Size: 



62<t 



Entry Points: 



XDUMP 

SAVE 

RESUME 

XL0AD 

START 



This Is the SAVE command entry 

po I n t . 

callers: C0MDIR 

Subroutine to save a user. 
(Used by XDUMP and ENDL0G). 
callers: L0GA(ENDL0G) 

TSS resume command. 
callers: C0MDIR 

TSS restor command. 
caller: C0MDIR 

TSS start command, 
caller: C0MDIR 



Module: 



SAVR 



Function: 



Save and restore routine. 
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Size: 



2U68 



Entry Points: 



SAVCPU Subroutines to save basic user 
machine conditions, 
callers: CL0C, PMTA 

REST0R Subroutine to restore basic user 
machine conditions, 
callers: PMTA, RTRN 

L0N6SV: Subroutine to save complete user 
machine conditions, 
callers: ST0R 

LNGRST: Subroutine to restore complete user 
machine conditions, 
callers: SAVC, ST0R 



Module: 
Function: 



SCDA, B, C, D, E, F, G, H 



Scheduling, time accounting, and monitoring, 
Including all subroutines. 



Size: 



A 


1567 


B 


i*21 


C 


523 


D 


22 


E 


171* 



F 266 
G 73 
H 20 



Entry Points; 



SCHEDL Entry to notify scheduling algo- 
rithm that something has happened, 
callers: CL0C, CTRL, L0GA, MAIN, 
PMTA, SAVC, ST0R, ADPI 

M0NSCD,M0NINF Monitoring 
caller: PMTA 



Module: 



ST0R 



Function: 



Storage allocation algorithm module. 
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-<>, »• 


Size: 2165 




k 


Entry Points: 

DUMP 


Subroutine to dump user onto disk. 
callers: CTRL 


' -~ 


UNDUMP 


Subroutine to restore a user from 
the disk* 
callers: CTRL 


■ 


FREEUP 


Subroutine to freeup N words of 

memory B, 

callers: CTRL, PMTA, SAVC 


• - 


Module: TC#R 






Function: Typewriter coordinator - break processor. 


7 


Size: 5205 




9 


Entry Points: 

TCOORD 


Subroutine to collect Input char- 
acters Into messages and look for 
- break' 'Clwr.acters./ 
callers: CL#C 




WRFLX 


Subroutine to write a message on a 
typewriter* Follow message with a 
carriage return, 

callers: CLfC, CTRL, L0GA, LfGB, 
fCTC, PMTA, RTRN, STfR, SAVE 


- 


WRFLXA 


Subroutine to write a message on a 
typewriter. No carriage return 



I ..-. _* 



provided. 

callers: CL#€, LfGA, PMTA 

RSSRB. Subroutine to reset a user's 
secondary rm»d buffer, 
callers: RFLX 

T0P00L Subroutine to place an Input 

character In the character pool 

buffer, 

callers: ADAPCRDTELY), HIGH 
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RDLINE Obtain an Input line from break 
processor, 
caller: CL0C 



Module: 



TST0 



Function: 



7750 storage allocator. 



(MAD) 



Size: 



25<» 



Entry Points: 



TGET Subroutine to obtain a block 
of 7750 storage, 
callers: AP75 

TGIVE Subroutine to give back 
a block of 7750 storage, 
callers: ADAP(RDTELY), HIGH, AP75 

TRESET Subroutine to discard all of a 
user's present output stored 
In 7750. 
callers: AP75 



Module: 



UNIT 



Function: 



Assigns logical unit numbers to consoles 



Size: 



21*7 



Entry Points: 



ASNUNI Subroutine to assign a logical 
unit number to a physical unit. 
callers: ADAP, HIGH 

US2BS Subroutine to look up a physical 
unit number given a logical unit 
number, 
callers: ADPI, AP75 
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BS2US Look up logical unft number gfven 
physical unit number, 
callers: ADPI, AP75 

HRSUNI Subroutine to erase logical unit 
assignment, 
callers: CL0C, L0GA 



Module: 



UTRP 



Function: 



Process user traps, 



Size: 



1*228 



Fntry Points: 



ATRAP Process data channel trap 
from channel A. 
callers: MAIN, channel A 
data channel trap. 

BTRAP Process data channel trap 
from channel B. 

callers: MAIN, channel B data 
channel trap. 

STRTRP Process STR in a user's program. 
callers: MAIN, STR trap. 

FLPTRP Process floating point traps 
In user program, 
callers: MAIN, floating point 
trap. 

CTRAPS Subroutine to check for waiting 
traps, 
callers: RTRN 

UPCL0C Subroutine to update core clock 
for current user, 
callers: CL0C 
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